Is there a good Java/Kotlin lib for handling dates...

# announcements

[Nezteb]

Is there a good Java/Kotlin lib for handling dates? Something similarly usable as Moment.js

[Shawn]

JodaTime is the gold standard on JVM

[BreadMoirai]

JodaTime was created to address issues with the java date and time implementation prior to java 8. With java 8, there is a new java.time package that resolves the same issues JodaTime resolved.

[Shawn]

ah, true, forgot about JSR-310

[BreadMoirai]

If you want a kotlin datetime lib for multiplatform usage you can look at https://github.com/korlibs/klock. Not sure if there are other alternatives atm

[Nezteb]

Oh neat; thanks y’all!

[gildor]

if you need this only for JVM I would highly recommend to use java.time rather than klock (or other alternatives)

[4ntoine]

Hi, guys. @gildor Can you please explain the reason? We need multiplatform DateTime, but starting with just JVM impl for now. What’s your suggestions on that? Any multiplatform alternative to klock suggestions?

[gildor]

@4ntoine The reason is that java.time is very well designed API that has good, successful predecessor (joda time), it designed to prevent usual programmer’s errors when you work with date and time by separation of concepts Local and Zoned time with explicit convertation between them.

It would be good to have something like this on MPP, but until this it really depends on your use case and features what you need, maybe you can solve it with a couple of expect functions, but if you writing MPP calendar app than it will be not enough, but simple MPP wrappers over platform time APIs also probably not enough.
There is a few attempts/ideas to reimplement jsr-310, but nothing successful, as I know

[4ntoine]

Yeah, i can clearly see the motivation in Java - old API was really bad for everyday use. However when it comes for multiplatform, there are probably other aspects. eg. why klock just did not have the same API for common from the very beginning?

[4ntoine]

and why current klock api is worse than java.time?

[gildor]

klock just did not have the same API for common from the very beginning

Because JSR-310 doesn’t exist on other platforms

[gildor]

it’s easy (but quite tedious) to define common API that does exactly the same what java.time does and map it using actual on java.time

[gildor]

but it’s huge project to implement it also for JS (but maybe you can find some existing library), or especilly for native

[4ntoine]

thanks for sharing your thoughts. However JSR-310 is not the only source of truth in this world 😉 I will rephrase my question: “Why java.time should be preferred to klock in Multiplatform project”?

[4ntoine]

BTW why java.time source code can’t just be rewritten in kotlin? basically in klock only 3 methods are `expect`ed (from quick look)

[gildor]

Not only of course, but implement whole date library from scratch is a big project

[gildor]

I remember a few people talked about converting java time to Kotlin but I never saw any real attempts

[gildor]

Tho, I don't think that it is impossible

[gildor]

I think the main reason is also because of 98% of cases everyone uses very basic features of date API, and a couple of expect declarations solve their problems

[gildor]

Also jsr310 is not the only source of truth, but it's just good API, better than most of other, so if question "what should I use for JVM" is pretty clear for me, attempt to use some other solution just because it has some Kotlin imperative sugar is probably bad idea imo

[4ntoine]

ok, i see your point. I just want to note this project (https://github.com/Doist/kotlinx.time) that looks pretty close to original API (and source code).