Hey everyone! So I've been working on a multiplatform date-time library called Island Time. It's a "from scratch" Kotlin library that draws heavily from java.time (since they got a lot right). It's still early in development, but here's a run down on some of the features that are already in place: - Support for JVM, Android, iOS, and macOS - Full timezone support on each platform - Date-time primitives like Instant, Date, Time, DateTime, ZonedDateTime, and so forth - Reading and writing to ISO representations - A DSL for defining custom parsers - Integration with Kotlin ranges and progressions Probably the biggest absent feature right now is support for custom and localized formatting. In preparation for an initial release, I'm very interested in getting any and all feedback to help flush out the API, find all the warts, and prioritize issues and features. If you have any ideas on how to make a better time library or you'd like to collaborate, please let me know. Development snapshot builds are available if you want to want to try it out. You can find more information on the GitHub page: https://github.com/erikc5000/island-time . I've started filing design-related issues there to provide a forum for discussion on specific parts of the library's design in effort to start opening it up more.

Interesting. I’ve also got a version of java.time that’s essentially feature complete for mac/ios, but kind of put it on the shelf for a bit. Android recently released desugaring for java.time, so I’m thinking the approach of doing an expect/actual on top of that may be the way to go, but will check out your lib.

Island Time currently relies on platform APIs for time zone information. So on JVM, it uses java.time under the hood. Without desugaring, a separate artifact that uses the ThreeTenABP project is required. I haven't tested with Android Studio 4.0 yet, but hoping the need for that artifact goes away.

Yeah, that was part of the “putting it on the shelf”. Waiting to see how that played out. You should be able to. I wanted to avoid the backport and tzdb altogether, if possible.

The tests are all written from scratch. Definitely need to work on expanding them.

I ported from java.time. Brutal. About 3k. It’s also a lot slower on native, so there was a lot of investigation still to do.

And what about https://github.com/korlibs/klock?

Will it be easy to convert your types to java.time types?

@thevery: I think anyone used to using java.time would agree that Klock is a big step backwards. The design isn't really fixable.

@Erik Christensen have you considered just using actual/expect typealiases to the

java.time

classes, so your types are completely interoperable with

java.time

on the JVM?

That’s kind of what we’ve been looking at now that desugaring will let you have java.time api on android earlier than api 26, but not sure any of that will every see daylight.

@Casey Brooks: There are pros and cons to doing that. I elected not to go that route when I started writing the library for a few reasons. For one, using typealias is quite restrictive, forcing you to implement an existing API in almost exactly the same way on the other platforms. I wasn't sure what obstacles I might run into trying to do that with a rather large API surface area and potentially numerous dependencies on other Java-only library components. Moreover, I didn't want to be tied to the java.time API. It's a good library, but it's a Java library -- not a Kotlin library. The goal is to create a library that borrows a lot of the concepts from java.time/Joda Time/Noda Time, but that's more extension-oriented and takes advantage of inline classes, lambdas, and so forth to create a date-time DSL that feels natural when programming in Kotlin. That said, it's possible that typealiases may be quite adequate in some places and future compiler features may change everything.

On the subject of typealias, the “safety valve” from their restrictive nature is extensions. I’m actually working on that part of the Boston talk right now…

@Erik Christensen do you have a strategy relating to time series resampling? this is something on my todo list.

@jimn: I'm not sure I understand what you're looking for specifically. There is support for intervals and you can iterate over them at varying levels of precision. For example:

for (instant in start until end step 10.nanoseconds) {
    // Do something
}

that looks like a good start. im looking for val (start,end)= instant to instant+1.day rows.filter{it.timestamp between start to end }.map{::qty}.sum() // ... it.timestamp in start until end ... //as good?