Hi there, I'm trying to figure why the use of LocalDateTime feels discouraged. The docs say "The arithmetic on LocalDateTime values is not provided, since without accounting for the time zone transitions it may give misleading results.". Could you provide an example of such a mistake? I'd love to do

LocalDateTime.now() + 10.hours

, and I struggle to see what's wrong with it.

I initially wrote an answer but I'm pretty sure it was wrong... Curious about this too 👀

If you take for example March 26, 2023, 22:00 as a value for the

LocalDateTime

then it's ambiguous what happens if you add 10 hours to it because that's when daylight saving time starts. If you just add 10 hours to the clock it would be 8:00, but if just waited 10 hours it would be 9:00.

Well, that's the thing.

LocalDateTime

isn't timezone aware, is it? So arithmetics could be defined without any time zone, leap second, etc.. considerations

No because "10 hours later" depends on the time zone.

What I'm saying is that it could be a choice

Implementing it like that would encourage incorrect date/time calculations.

right, I can see how people could expect the wrong thing

I even wonder what the use case is for the "+10 hours" example mentioned in the original question. My first guess is that it should be implemented in a timezone-aware manner.

I had to do that recently, let me see if I can dig the use case

So in this case using UTC time-zone is incorrect. You'd have to use the time zone of where the conference takes place. If the conference was across a DST change boundary this would give the wrong result. I know it's quite an edge-case in your example, but an API should always be correct.

Yep, agreed

No worries 😉 Unfortunately working with date/time is always complex and/or annoying. The time zone rules across the world are a hot mess

Thanks gentleman for this great thread. Regarding "I even wonder what the use case is for the "+10 hours": I'm working out a production schedule, and was just wondering if the more minimalistic LocalDateTime would be sufficient (since the factory is clearing never moving to a different time zone). However, I understand now that the timezone also models summertime/wintertime transitions, so Instant is the correct choice.

Digging up this old thread. I have a usecase where some businesses consider 2AM or 3AM to be the end of the day, sometimes known as a closeout time. I want to figure out what the business date is of someones particular shift. So if I finish a shift at 2023-01-02T01:59:00 and the closeout time is 2:00:00, then the business date for the end of the shift would be 2023-01-01. If I finish a shift at 2023-01-02T2:00:00, then the business date for the end of the shift would be 2023-01-02. Using the java api I can do this to figure it out:

zonedDateTime.toLocalDateTime().minusHours(closeoutHour).toLocalDate()

But in kotlinx.datetime we can’t do arithmetic on the LocalDateTime. However, in this case doing arithmetic on the Instant could get us wrong answers depending on daylight savings time, since the closeout time does not shift. Is there some gotcha I’m missing about the java api in this use case?

Why do you have to substract? Can't you compare to

2

instead of

0

?

Like the example I have above? I guess that’s a fair point. Maybe since it’s not completely necessary to subtract hours in this use case it’s still more beneficial to lock the api down to prevent confusion.

If clocks are shifted back due to DST and it takes three actual hours to get from midnight to 02:00, or if the clocks are shifted forward and it takes just an hour to do so, do the businesses adapt the schedule? In other words, what is more important: the mark "02" on the clocks or the actual length of the workday?

Just the mark “02”. The actual length of the workday doesn’t matter.

Also, the subtraction approach is a bit more error-prone:

zonedDateTime.minusHours(closeoutHour).toLocalDate()

would be incorrect, but it looks almost the same.

Just bumped into this (

LocalDateTime.plusHours()

). Interesting that Java made the opposite choice.