and this is experimental in what way? like, slated for un-experimentalness soon?
2 years ago
* This annotation marks the experimental preview of the standard library API for measuring time and working with durations.
* > Note that this API is in a preview state and has a very high chance of being changed in the future.
* Do not use it if you develop a library since your library will become binary incompatible
* with the future versions of the standard library.
* Any usage of a declaration annotated with `@ExperimentalTime` must be accepted either by
* annotating that usage with the [OptIn] annotation, e.g. `@OptIn(ExperimentalTime::class)`,
* or by using the compiler argument `-Xopt-in=kotlin.time.ExperimentalTime`.
In addition, classes like
are based on
which are experimental themselves.
Zach Klippenstein (he/him) [MOD]
2 years ago
Generally, experimental APIs are fine to use in app code as long as you're willing to accept the risk of potentially having to update call sites when you update your kotlin version in the future. They're not safe for libraries since they might break binary compatibility.
This is application code which can undergo migration when upgrading to another kotlin version so not a biggie, still I am pondering if depending on Optin experimental timemark is easier than depending on https://github.com/markov/lucid-time when it comes to the upgrade effort
but probably timemark is still the way to go
eh, lucid-time did not even solve all of what I wanted to express, forget about that
hmm how to convert an OffsetDateTime to a TimeMark