:mega: It's `2020-08-13T15:15:00Z`, a good time t...

# announcements

[ilya.gorbunov]

📣 It's 2020-08-13T15:15:00Z, a good time to announce the first milestone of kotlinx-datetime library, v0.1, has been published
https://discuss.kotlinlang.org/t/kotlinx-datetime-0-1-has-been-published/18766

[Dominaezzz]

WOOOOAAAAAHHHHHH!!!!

[Nir]

Did it end up with the double/float based duration type?

[streetsofboston]

Quick question: for the JVM, it uses the java.time implementation(s). Is there anything that Android devs need to be aware of, since java.time is not available on all android devices (and would it work with the current state of desugaring)?

[Dominaezzz]

https://github.com/Kotlin/kotlinx-datetime#implementation

[Dominaezzz]

since java.time is not available on all android devices

I thought that was recently fixed, no? It was backported iirc.

[streetsofboston]

Through desugaring (D8), a large part of the java.time has been backported, but not all of it. Also, would desugaring work this way when used with kotlinx-datetime….?

[ilya.gorbunov]

We haven't tested it yet, but we use a small part of java.time API, so desugaring should cover that.

[ilya.gorbunov]

@Nir, yes, we use Duration type from stdlib in some operations with Instant.

[Robert Jaros]

Why js-joda was choosen for JS implementation? It will add at least ~40KB to the compressed bundle size. It's very much in my opinion. DayJS would add only 2KB.

[ilya.gorbunov]

js-joda is chosen for the first version because of its similarity with java.time API. We can consider backing JS implementation with a different library further, or just porting only required parts of ThreeTenBP to K/JS.

[Nir]

@ilya.gorbunov tbh, it's really disappointing. Anyone who works in a field where a lot of attention is paid to times, durations, etc, will tell you that integer representations are widely used and with good reason

[Nir]

It's the approach in Java, C#, C++, etc

[ilya.gorbunov]

The internal representation of all types is based on integer numbers and if you don't like Duration type, there's a way to do operations without it.

[Nir]

Okay, I thought you just answered my question of whether you ended up with a float as "yes"

[Nir]

I participated in the github discussion about the Duration type for the standard library, and things seemed to be leaning towards using a double

[Big Chungus]

Is this available on wasm?

[Nir]

@ilya.gorbunov This is what I mean:

public inline class Duration internal constructor(internal val value: Double) : Comparable<Duration> {

[Nir]

unless it's changed since

[serebit]

Any particular reason Linux X64 is the only Linux target, but all Apple targets are included? Would be nice to see more Linux targets covered, like Arm64, which could (to my knowledge) share all the same code

[russhwolf]

What's the best place on Slack for questions/feedback? I don't have anything yet, but want to follow whatever discussion happens.

[Dominaezzz]

Might as well start a channel called kotlinx-datetime (or datetime).

[Big Chungus]

#C01923PC6A0

[Erik Christensen]

@ilya.gorbunov As the author of another date-time library, Island Time (https://islandtime.io), I feel compelled to chime in. At the time I got started on it, the plans for a kotlinx library were quite murky. The lack of a date-time library on par with java.time was a real roadblock to making my own Android app multiplatform-ready. It's been sort of an all-consuming side-project that I've sunk entirely too many hours into, but I've learned a heck of a lot about dates and times and the design of other libraries in the process.

I don't know the planned scope for kotlinx-datetime, but I'd definitely be open to collaboration, synchronizing efforts, contributing parts of the code, or anything along those lines where (and if) it makes sense. It may be that there are conflicting design goals and that's just not realistic, but I wanted to throw it out there in any case.

Island Time seems to be a lot further along in development, so it may provide some design insights at the very least.