Open soywiz opened 4 years ago
We currently are using Klock and while updating to Kotlin 1.4 we took a look at kotlinx-datetime to see if it made sense to switch to it. However since we have a multilingual app this paragraph made it a non-starter:
The library is based on the ISO 8601 international standard, other ways to represent dates and times are out of its scope. Internationalization (such as locale-specific month and day names) is out the scope, too.
Just wanted to let you know that there still is a place for Klock since in my opinion kotlinx-datetime is only usable in an English-only app
@dalewking I would still create an issue on kotlinx-datetime to let them know your use-case. As I see it, as a 0.1 version that might be a bit out of scope, but I think it is reasonable for them to consider that for future versions.
Of course, as long as there is people using Klock the plan is to continue releasing versions for the coming Kotlin versions. And I still have the inline class requirement for the rest of the korge stack
https://github.com/Kotlin/kotlinx-datetime
Since it seems that it actual/expect things Klock has a different approach. It needs allocation-free primitives for the rest of the korlibs stack, so maybe the approach will be to create a klock-kotlinx-datetime artifact providing interoperability while still having an allocation and dependency-free version.