https://kotlinlang.org logo
Join Slack
Powered by
does anyone have any suggestion for date-time libr...
# multiplatform
p
does anyone have any suggestion for date-time library? I would kind of want to avoid 
java.time
(Android reasons). Any other robust alternatives?
f
p
isn't this just a type-alias for java.time, for the most part? 🙂
f
Oh by the "Android reasons" you meant that 
java.time
is only since Java 11? You can desugar that to support earlier versions of Android
p
yeah, I need to bump minApi for Android version, or include core library desugaring magic
f
What's wrong with desugaring? And I doubt you'll find something more robust than first-party kotlin library
☝️ 2
☝🏾 1
p
I think it impacts build time and adds potential random for runtime exceptions
🚫 1
I'm mainly wondering, if there's anything else out there
j
Doesn't the desugaring only happen if needed? So if you develop on a modern device it won't affect you, but I'm not sure.
e
FWIW I've been using desugaring since it became available and it hasn't impacted build times or caused any runtime issues
➕ 1
j
Same here, but I didn't measure it. Have had desugaring enabled since forever, it feels.
p
I've had a runtime exception at some point, exactly because of some java.time stuff
Can't say for sure about performance, I was presuming it's not free 🙂
m
kotlinx-datetime
is multiplatform and even supports WASM. So, what is the problem with it? I am using it and did not have any problems so far.
✅ 1
e
Depends on what features you need. kotlinx-datetime still doesn't have the full coverage of java.time
r
I use 
kotlinx-datetime
as well in an app that relies heavily on date time , but unfortunately as @eygraber said, it doesn’t have everything java.time has, but you can overcome this with a bit of extra code, I wrote an article about it, could be useful Kotlinx DateTime manipulation for KMP
👍 2
m
@eygraber That’s true of course but the OP did not mention any missing features. @Raed Ghazal That may indeed be useful.
✅ 1
@Raed Ghazal Your code is indeed very helpful and solves a few problems. The article contains an error though. The last function
Copy code
actual fun parse(strDateTime: String)
doesn’t compile because it doesn’t specify a return type. I am also wondering why you are using 
Locale.ENGLISH
here instead of 
Locale.getDefault()
elsewhere. Similar problem with format too.
thank you color 1
r
thanks for reading and pointing that out! let me check that tomorrow
Hey @Michael Paus just updated the article with the fixes to the issues you mentioned, thank you for bringing them to my attention 🙏
🙏 1
m
One more idea. When I started using your extensions I immediately realized that I needed the following modifications.
Copy code
fun LocalDateTime.Companion.now(timeZone: TimeZone = TimeZone.currentSystemDefault()): LocalDateTime
Sometimes you just want the current time in your default time zone but sometimes you also want to know the current time in some other time zone. For me it is most often the Zulu time that I am interested in too. Providing default arguments for all now() methods solves that problem.
r
Good points! the usual usecase is current timezone, or at least in my app, but the article provides foundation for the most used stuff then you can modify it however you want for your case easily another example: in the article I just provided an example of parsing a full LocalDateTime
Copy code
fun parse(strDateTime: String): LocalDateTime
while in my application I have those 3 functions
Copy code
fun parseToLocalDateTime(str: String): LocalDateTime
fun parseToLocalDate(str: String): LocalDate
fun parseToLocalTime(str: String): LocalTime
👍 1
maybe we can create a datetime extension library that provides all those and more for even easier implementation for the developers 😄 I’m down for that if someone is interested in helping!
m
Sounds like a good idea. The standard time package leaves a lot of room for improvements.
r
Yeah, then will probably start with it tomorrow!
“tomorrow” wasn’t pretty accurate apparently 😅 but the library is finally here! check out my other message cc @Michael Paus @eygraber @Peter since you guys were interested in kotlinx.datetime library https://kotlinlang.slack.com/archives/C3PQML5NU/p1704540181657349
👍 1
m
Great, but it doesn’t help me much if you don’t support the desktop target and for the future also WASM and all the other targets where kotlinx-datetime is available.
r
Right, my app only works on Android and iOS so that was whats already implemented and I extracted the datetime code into a library, but we can support more platforms, the only missing piece is actually the formatter, which can be easily added for any platform I can look up how to do this on desktop and WASM, but you can also contribute by opening a pull request if you already have an implementation that you use! (Also actually desktop actually can use the same implementation as android since it runs on jvm)
m
Right, desktop should be simple to add then and that’s what I am primarily interested in. The rest is for the future.
✅ 1
Should 
instantBetween
not rather be 
durationBetween
?
r
good point, let me change this quickly before anyone uses the library
actually I think its not super intuitive in its current format maybe this looks better? what do you think
Copy code
fun LocalDateTime.durationTo(
    end: LocalDateTime,
    timeZone: TimeZone = TimeZone.currentSystemDefault()
): Duration {
    val start = this
    if (end < start) throw IllegalArgumentException("end must be greater than start")

    return end.toInstant(timeZone) - start.toInstant(timeZone)
}
j
durationUntil
?
r
better, will rename it
e
Will check this out for a project soon. Looking forward!
✅ 1
r
Cool! don’t hesitate to share your feedback or any issues you encountered so I can fix it
7 Views
Open in Slack
PreviousNext
Powered by