I'm looking for an exhaustive list of why using kotlinx.datetime instead of java.time api. - Multi-p...

# kotlinx-datetime

[Renaud]

I'm looking for an exhaustive list of why using kotlinx.datetime instead of java.time api.
• Multi-platform?
• TZ Data up-to-date ?
Edit:
• Decoupled from language release

[kevin.cianfarini]

Natively serializable by kotlinx serialization

[kenkyee]

Does it use tzdata now? Used to not...

[Renaud]

True, so how can we get an up-to-date timezone dataset then?

[kenkyee]

That's why we use threetenabp on Android...

[Renaud]

But ThreeTenAbp says:

Attention: Development on this library is winding down. Please consider switching to Android Gradle plugin 4.0, java.time.*, and its core library desugaring feature in the coming months.

[Renaud]

So basically saying: "use java.time", right?

[Renaud]

But kotlinx.datatime uses java.time under the wood or I am missing something?

[Renaud]

To update java.time , this library was developped https://github.com/ZacSweers/ticktock

[kenkyee]

Yep, on Android at least, just use the desugaring libs

[Renaud]

What do you think make the kotlinx.datetime library useful then?

[kevin.cianfarini]

MPP is the biggest one for me with serialization in a close second

[kevin.cianfarini]

If you’re doing Android only then it’s not worth the dep. There will be more samples online for java time than kotlinx

[kevin.cianfarini]

It would be fantastic if it had a way to natively update tz info, but I suppose that’s less of a concern with kotlinx since it’s decoupled from the language

[mbonnin]

+1 on MPP. Also usage is a bit more idiomatic if you're used to Kotlin and extension functions:

// kotlinx
someIsoStr.toLocalDateTime().date

vs

// java.time
LocalDateTime.parse(someIsoStr).toLocalDate()

[kevin.cianfarini]

The more I think about it the more I also like that it's decoupled from the language release cadence

[Renaud]

That's a valid point indeed