kotlinx datetime seems to be languishing. would lo...

# multiplatform

[tylerwilson]

kotlinx datetime seems to be languishing. would love to see more on that, esp. with general parsing support. 🙂

[mbonnin]

Do you have anything specific in mind?

[tylerwilson]

Here is one I +1 back in 2021: https://github.com/Kotlin/kotlinx-datetime/issues/58

[mbonnin]

I see. I think the important/hard part there is the Locale handling. I remember seeing something about this, let me see if I can dig the link

[mbonnin]

There's a bunch of discussions around this in #kotlinx-datetime like this one for an example

[tylerwilson]

There are quite a few issues tagged 'formatter'. I wrote my own DateTime expect/actual to handle it, but if it were built into this multiplatform lib it would allow me to remove quite a bit of code.

[tylerwilson]

I deal with a backend API that uses like 10 different date/time formats. 😞

[mbonnin]

Ah, this was the message I was looking for: https://kotlinlang.slack.com/archives/C01923PC6A0/p1666261305259639?thread_ts=1666196134.778889&cid=C01923PC6A0

[mbonnin]

(also: 10 different formats, Yikes 😱 !!)

[tylerwilson]

Thank you for the link. Looking forward to that next release.

[zt]

I've been looking for a formatting feature too. Especially on Android with how bizarre formatting of time and dates and limited by the API level

[efemoney]

I dont think its a limitation anymore on Android because of D8. Feel free to fall back (from kotlinx datetime) to any java time APIs, they will be desugared on API levels that dont natively support them

[tylerwilson]

I use desugar for Java APIs, it is nice to have one set of code for jvm/android. The issue is the multiplatform (iOS, macOS, etc.) aspect of it...