Hey hey! In `2.1.20` `Instant` and `Clock` from `k...

# stdlib

[Filipp Zhinkin]

Hey hey! In 2.1.20 Instant and Clock from kotlinx-datetime were added (and slightly modified along the way) to the standard library as kotlin.time.Instant and kotlin.time.Clock and remained experimental since then. There were almost no feedback on these types (except how painful was the removal of corresponding classes from the datetime library), so they are candidates for stabilization in 2.3.
Please let us know if there are any issues with kotlin.time.Instant and kotlin.time.Clock API or implementation, so it could be updated before stabilization, if needed. Thanks!

[Robert Jaros]

I'm sure it was long discussed somewhere, but I would really like to understand why do we need to have kotlin.time.* and java.time.* on the JVM target? If it only concerned an external library like kotlinx-datetime it would be understandable - it's just some API and there are other libs out there. But putting that in the stdlib is a "one way trip". We will end up converting between Kotlin to Java all over our code forever. It reminds me Scala's collections.

[Robert Jaros]

Why can't we have typealiases on the JVM and nice Kotlin API based on extension functions? Like with Kotlin lists we can easily use on JVM?

[kevin.cianfarini]

Instant in Java Time is represented by a slightly different time scale than kotlin Instant, for one. Java uses the Java Time Scale which is a mix of the UTC smeared leap second time scale and UT1 time scale. Kotlin instant only uses smeared leap second time scale.

[kevin.cianfarini]

The KEEP for Instant and Clock don't mention anything about typealiases to java time, though, so I am curious. I also searched through kotlinx-datetime PRs and issues and didn't see anything of note. Curious to hear from Flipp on this.

[Filipp Zhinkin]

@Robert Jaros, we reviewed an option of mapping an Instant to java.time.Instant here: https://github.com/Kotlin/KEEP/blob/main/proposals/stdlib/KEEP-0395-instant.md#implementation-on-the-jvm

Briefly, the main reason for not doing that, is that kotlin.time.Instant (or, kotlinx.datetime.Instant back then) behavior diverges from java.time.Instant.

[Filipp Zhinkin]

Typealiases could be considered a simpler version of mapped types: they have all the same downsides of mapped types, but it is also impossible to rename functions and properties (which is quite painful, but possible with mapped types).

[kevin.cianfarini]

Any chance y'all would consider offering a clock DSL like the following?

val staticClock = Clock { myInstant }

I don't think this could be a fun interface for api compatibility reasons, but a function could be added which mimic it maybe?

fun Clock(provider: () -> Instant): Clock = object : Clock {
  override fun now() = provider()
}

[kevin.cianfarini]

In almost every single project I have that does things with instant I have a notion of a static clock for testing purposes. That's the use case I'm thinking about with this.

[kevin.cianfarini]

I also don't feel strongly about this and if there's too many downsides it's likely not worth fighting for

[CLOVIS]

^ IMO that should be provided by the test framework with framework-specific integrations, especially now that it's in the stdlib. Prepared already does, Kotest supports java.time. So maybe that function could be in kotlin-test, but I don't think it should be in the stdlib itself.