With an application.yml like so:

my-app:
  duration: 4h

and a class property like so:

import kotlin.time.Duration

@Service
class MyClass(
   @Value("\${my-app.duration}") private val followDuration: Duration
)

getting

Unsatisfied dependency expressed through constructor parameter 3: Failed to convert value of type 'java.lang.String' to required type 'long'; For input string: "PT4h"
...
Caused by: org.springframework.beans.TypeMismatchException: Failed to convert value of type 'java.lang.String' to required type 'long'; For input string: "PT4h"
...
Caused by: java.lang.NumberFormatException: For input string: "PT4h"

Spring boot version: 3.1.4 Kotlin: 1.9.20-Beta

Comment From: Sap004

@dpozinen I think you are facing this issue because

converter provided by Spring Boot works with java.time.Duration and not kotlin.time.Duration

Comment From: dpozinen

@Sap004 yes I assume that is the case as well, hence the feature request

Comment From: Sap004

@dpozinen I am currently working on addressing this issue. I'll be submitting a pull request shortly for review

Comment From: wilkinsona

I'd like to keep this as waiting for triage until we know what's necessary. If it requires further Kotlin code we'll need to consider if the potential benefits justify that complexity. There's also the Framework side of things to consider such as https://github.com/spring-projects/spring-framework/pull/30396.

Comment From: wilkinsona

@Sap004 please be aware that, unfortunately, there's a good chance that a PR will be declined at this time. Things are moving towards duration parsing being handling in Spring Framework. https://github.com/spring-projects/spring-framework/pull/30396 is tracking that and we may not want to add any more Boot-specific features in this area until that PR's been resolved one way or another.

Comment From: philwebb

We discussed this today as a team and decided that we don't think this is a good idea for us to implement. The fact that our current DurationStyle enum is tied to java.time. types along with the fact we have a @DurationUnit annotation that clashes with a similarly named Kotlin type makes us think that this will be confusing for users.

Since Kotlin has an extension method to convert a java.time.Duration to a kotlin.time.Duration we recommend that the Java type is used for binding and extension method be used whenever a Kotlin type is needed.

Comment From: neeme-praks-sympower

Since Kotlin has an extension method to convert a java.time.Duration to a kotlin.time.Duration we recommend that the Java type is used for binding and extension method be used whenever a Kotlin type is needed.

The best thing about kotlin.time.Duration is the support for human readable period definitions such as 1.5s. Compare that to PT1.5S. More readable format is especially important in case of configuration files (the main use-case for me). Couldn't you just detect that if the target type is kotlin.time.Duration then parse it as the Kotlin type?

Comment From: philwebb

@neeme-praks-sympower We're not keen to add any more complexity to the Duration parsing in Spring Boot, but I do think the period parsing is interesting. I've added a comment to https://github.com/spring-projects/spring-framework/pull/30396#issuecomment-2037854277 to see if Spring Framework can consider that feature for java.time.Duration parsing.

Comment From: simonbasle

I plan on getting back on the Spring Framework side of things soon, and I'll be only talking from Framework perspective here.

Regarding the Kotlin-style parsing, I fear this might be a bit too involved to fully support decimal parts. And without it, the simple style seems enough?

I also wonder if the other Kotlin style - the one where multiple components in different units can be combined, separated by a space - would be easier to parse AND more human readable. any opinion on that one ?