Howdy Kotlin friends :wave: I've been recently wo...

# feed

[Sami Eljabali]

Howdy Kotlin friends 👋

I've been recently working on Kotlinx Datetime Fun, a library aiming to remove the need in ever write your own datetime util method.

Project is now currently used production and at a point worth sharing with you all.

Feedback & contributions is most welcome!

Let's go team Kotlin!

[hfhbd]

Sorry to say it but your LocalDate arithmetic is very naive. The reason to not include it in the official library is to handle all the edge cases, and there are many edge cases, the most common is day light saving. On this day, the day does not have 86.000 seconds. So you need to always pass a time zone and don't handle the calculation by ourself but delegate it to the system/database.

[Sami Eljabali]

Thanks for the feedback @hfhbd, mind specifying which method you're referring to exactly?

[hfhbd]

https://m.youtube.com/watch?v=-5wpm-gesOY

[hfhbd]

https://github.com/sami-eljabali/kotlinx-datetime-fun/blob/main/library/src/commonMain/kotlin/kotlinxdatetimefun/localtime/extensions/LocalTimeMutatingExtensions.kt

[hfhbd]

https://github.com/sami-eljabali/kotlinx-datetime-fun/blob/main/library/src/commonMain/kotlin/kotlinxdatetimefun/localdatetime/extensions/LocalDateTimeMutatingExtensions.kt

A day must not end at 235959, you also do have leap seconds

[CLOVIS]

@hfhbd AFAIK leap seconds are not implemented by kotlinx-datetime

[CLOVIS]

But I agree, LocalTime.plusHours() & co are dangerous

[CLOVIS]

@Sami Eljabali as an example;

What's the time 2h after 2am?

• Usually, it's 4am
• In most of Europe, on March 29th, it's 3am
That's why KotlinX.Datetime doesn't have the method, it's too easy to forget these cases

[Sami Eljabali]

But local time on its own has no association with timezone and date. I'm looking at this file in particular that Philip mentioned.

[Sami Eljabali]

Meaning 2AM + 2 hours is always 4AM right?

[CLOVIS]

As I just said, in two weeks, it won't be

[Sami Eljabali]

Maybe in a developer's mind they're thinking of a zoned time

[Sami Eljabali]

But I think I'm seeing what you're getting at

[Sami Eljabali]

One can't help but think of local times mentally without thinking of a timezone related to it

[CLOVIS]

All times are zoned if humans read them. If you display that information to a user, it's going to be wrong for them

[Sami Eljabali]

Right, got you

[CLOVIS]

That's why you can't compare two times either, your code can't know if they are from the same timezone

[Sami Eljabali]

So I see why kotlinx datetime made everything local to avoid this

[Sami Eljabali]

But as a result, personally, when thinking of LocalTime that's devoid of Zones, think of it abstractly

[Sami Eljabali]

As in we're talking about time in a void sort to speak

[Sami Eljabali]

There and then in saying 2AM + 2 hours is 4AM is perfectly fine

[CLOVIS]

Yes, but none of the programs I write are in that imaginary world

[CLOVIS]

If you're making a game, then probably yeah it doesn't matter

[Sami Eljabali]

Got it, thanks for the immediate feedback

[Sami Eljabali]

It's most appreciated 🙂

[Sami Eljabali]

@hfhbd which of the methods are offending in LocalDateTimeMutatingExtensions?

[Sami Eljabali]

Nevermind, I think I see it

[Sami Eljabali]

fun LocalDateTime.minusYears(years: Int, timeZone: TimeZone = TimeZone.currentSystemDefault()): LocalDateTime =
    LocalDateTime(this.toLocalDate().plusYears(-years), this.toLocalTime())
fun LocalDateTime.plusYears(years: Int, timeZone: TimeZone = TimeZone.currentSystemDefault()): LocalDateTime =
    LocalDateTime(this.toLocalDate().plusYears(years), this.toLocalTime())

fun LocalDateTime.minusMonths(months: Int, timeZone: TimeZone = TimeZone.currentSystemDefault()): LocalDateTime =
    LocalDateTime(this.toLocalDate().plusMonths(-months), this.toLocalTime())
fun LocalDateTime.plusMonths(months: Int, timeZone: TimeZone = TimeZone.currentSystemDefault()): LocalDateTime =
    LocalDateTime(this.toLocalDate().plusMonths(months), this.toLocalTime())

fun LocalDateTime.minusDays(days: Int, timeZone: TimeZone = TimeZone.currentSystemDefault()): LocalDateTime =
    LocalDateTime(this.toLocalDate().plusDays(-days), this.toLocalTime())
fun LocalDateTime.plusDays(days: Int, timeZone: TimeZone = TimeZone.currentSystemDefault()): LocalDateTime =
    LocalDateTime(this.toLocalDate().plusDays(days), this.toLocalTime())

[Sami Eljabali]

I take in timezone but don't actually take it into account

[Sami Eljabali]

Where as I do with the other mutating methods

[Sami Eljabali]

Such as:

fun LocalDateTime.plusHours(hours: Int, timeZone: TimeZone = TimeZone.currentSystemDefault()): LocalDateTime =
    this.toInstant(timeZone)
        .plus(hours.hours)
        .toLocalDateTime(timeZone)

[hfhbd]

Yeah, please don't take the feedback negative. LocalDate, Timezones etc. are for humans only. And it is incredibly easy to shoot yourself into the foot, because it is crazy (or humans in general).

It really depends on your use-case, but you always need to include the timezone if you want to interact with humans or calculate anything.

[Sami Eljabali]

> Yeah, please don't take the feedback negative.
Not at all! I signed up for this 😄 I also want to get it right

[Sami Eljabali]

I'm a bit torn on removing local time mutations entirely, it's going to take some time for me to ingest Ivan's point and come full circle.

[streetsofboston]

http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time

http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time

[streetsofboston]

The fact that time-of-day calculations are time, location dependent and that rules change over location and time (updated local laws), and that certain locations do or don't take scientific updates to time-of-day (eg leap seconds and UTC, vs GMT, vs TAI and UT1 timezones).

Even big companies whose bread and butter is to get these calculations right have sometimes been wrong, bugs in their software.

[Stefan Oltmann]

Even Sun/Oracle wasn't able to get it right, so they basically adopted the de facto standard Joda Time, which (more or less) became the new Java Time API.

[Sami Eljabali]

Couple of releases later and made changes per everyone's feedback.

Great Kotlinx DateTime learning experience that helped me too better appreciate its design.

Thanks all!