In Java we have the LocalDateTime, LocalDate, LocalTime APIs.
And they’re very useful. When using Kotlin in the JVM, it’s easy to use that API.
But there’s no API for all other platforms, and it’s a very important one!
Are there any plans for Kotlin DateTime API?
If there are no plans, I’m very interested in contributing with that!
I think this shouldn’t be in the stdlib but as a separate lib (even if it’s blessed by Kotlin, ala kotlinx). Should be as thin of a greatest-common-factor you can get around Java 8+ date time and something like moment.js (and maybe std::chrono for KN). If done right with actual/expect and interfacing, can even have multiple impls for the same platform, e.g. joda option for old JVM like Android, date-fns for JS, ctime for KN, etc.
Jetbrains recently added a KEEP for a multi-platform random API. I think this shows that they are now slowly focusing on adding those basic but important APIs to the language. I guess we can expect to see more of those once 1.3 is released so maybe with 1.4 (I’m just guessing right now).
I think the fastest way of getting something like this is writing a KEEP yourself. If the API is just supposed to wrap around platform specific implementations it should not be to hard after that to get a prototype ready. But IMO the KEEP is the most important step, because I guess there will be some valid discussion about how the API should look and what interfaces/classes and functions it will need.
Isn’t kotlinx just the experimental part of the kotlin std-lib? Anyways, I think this should be part of the normal kotlin library just like random will be. Whether it should get it’s own package, I’m not sure maybe not. This will depend on the size.
Going on a bit of a tangent, but what is the difference between a Kotlin/JetBrains-blessed lib and something in the standard lib? To me it’s only that the latter doesn’t require explicit opt-in for use, potentially bloating distribution size in environments that don’t have compile-time dead code elimination (like the JVM). So whether it’s the in the standard Kotlin distribution, blessed by Kotlin, or whatever, the main point is that, like kotlin-reflect, it should not be part of the stdlib itself if it can be helped. I think random should be small enough that it’s really just deferring, but date/time has enough implementation decisions to be separate I’d say.
I also agree that it should be in the standard library.
Most web applications use some sort of date and time today. Most android applications that have any sort of data manipulation also uses some datetime.
In Java, java.time is in the standard library, and we don’t see much problem in that.
I believe it’s more beneficial to be added to the STDLib
If project jigsaw were there at the beginning of Java, I believe that many parts of the Java stdlib would have been opt-in libraries.
I’d like to have the date API as a separate opt-in library (kotlinx or whatever).
I have ported JSR-310 to kotlin-common. I have just few things to figure out, most importantly how to find default timezone in native and js. Any hints? I will publish it as soon as I figure those few things out
In case this helps anybody, here’s my implementation I’ve been using for a few years now:
(It was written before expects/actual, so you’ll have to add that yourself)
If anything this serves as a “me too” post 
I know it’s an answer from 2 years later, but I’m searching about it and I think it’s good to have that answer for people searching about it (just like me)