kotlin.time.Instant

[dkhalanskyjb]

This issue is for discussing the proposed transfer of kotlinx.datetime.Instant to the standard library as kotlin.time.Instant. The full text of the proposal is here.

PR: #387

[hrach]

Since "Implementation on the JVM" seems to be an open question and not fully answering this:

Is it the plan to copy the same implementation over as well? Wouldn't pure Kotlin implementation bring some benefits?

[dkhalanskyjb]

A pure Kotlin implementation would be somewhat easier to support, as we would not have to introduce workarounds for the discrepancies between the JVM implementation and ours. However, introducing our own implementation to the JVM could increase the bytecode size. In general, this is just an implementation detail. What is not an implementation detail but an observable behavior is whether kotlin.time.Instant can be passed to functions expecting a java.time.Instant (and vice versa) without any conversions. It's unclear how important this property is.

[CLOVIS-AI]

What is not an implementation detail but an observable behavior is whether kotlin.time.Instant can be passed to functions expecting a java.time.Instant (and vice versa) without any conversions. It's unclear how important this property is.

In my opinion, and from the codebases I have seen, this doesn't seem to be important as long as there is a .toKotlinInstant() (and back) extension.

[kevincianfarini]

discrepancies between the JVM implementation and ours
...
What is not an implementation detail but an observable behavior is whether kotlin.time.Instant can be passed to functions expecting a java.time.Instant (and vice versa) without any conversions. It's unclear how important this property is.

I know this is very late,but in my opinion ensuring there's no KMP discrepancies is much more important than transparent integration with java.time. Since this functionality is getting promoted to the stdlib, if a discrepancy is found between multiple targets it will no longer benefit from the nimble release cycle that kotlinx-datetime was able to provide. Resolving such an issue will take longer, and for something as crucial as Instant and Clock, could prevent people from considering KMP as a viable solution.

Edit: Also want to chime in that if we just typealias kotlin.time.Instant to java.time.Instant and we do find a discrepancy, won't we have significant difficulty resolving such an issue without also breaking binary compatibility to consumers of this API?