https://kotlinlang.org logo
Join Slack
Powered by
Hey everyone! So I've been working on a multiplatf...
# multiplatform
e
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.
🎉 10
k
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.
e
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.
k
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.
What’s the test plan? Writing from scratch or porting over?
e
The tests are all written from scratch. Definitely need to work on expanding them.
k
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.
If the classes/structure are similar there may be some value in just porting that, but test porting can be more difficult because of dependencies. “main” sources tend to limit dependencies, but test sources generally don’t have to worry about that. Yada yada, time library is a big effort. Congrats.
t
r
Will it be easy to convert your types to java.time types?
e
@thevery: I think anyone used to using java.time would agree that Klock is a big step backwards. The design isn't really fixable.
@robstoll: It should be relatively straightforward, I think. I'd like to at some point define a bunch migrations for Island Time using Kotlin's deprecation facilities to help automate the process of replacing calls where required in IntelliJ -- similar to what was done with Flow in coroutines to ease the migration from RxJava.
c
@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?
k
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.
e
@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.
k
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…
For firestore sdk
Each platform gets it’s own implementation, but you don’t need a whole parallel delegate class model. Not exactly the same thing, but I also wanted an implementation that wasn’t 100% “Java port” but could typealias with the bigger types. I very much went overboard with the firestore sdk and the empty typealias + extensions, but you can mix and match. Raw typealias can be quite inflexible, and inline classes I’ve found problematic.
j
@Erik Christensen do you have a strategy relating to time series resampling? this is something on my todo list.
e
@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:
Copy code
for (instant in start until end step 10.nanoseconds) {
    // Do something
}
j
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?
11 Views
Open in Slack
PreviousNext
Powered by