Then how do you express that something must happen at a date in the future at 4pm local time? If you use UTC based on today's expectation of daylight savings, they may have changed by the time this date happens.
For example, I read your comment three times, and I don’t know what you mean by “4 pm local time”. I don’t even have what I would consider to be a credible guess.
The whole concept of a computer belonging to a timezone works to some extent when that computer has a single human tenant, but it falls apart pretty quickly when the scope broadens.
But if I'm scheduling when I want my computer to reboot, I want that to be a fixed in time zone in my local time zone. And if I subsequently change my local time zone, I want it to remain at that time in the new local time zone, not the old one.
Yes, local time zones don't always make sense. But that is a far cry from saying they never make sense!
But yes, “reboot a laptop at 2am” is in the general category of alarm clock use cases, where a time (but not a date!) with a separately determined time zone makes sense.
The OP mentioned LocalDateTime, which doesn’t make sense for this use case.
Future shedule for humans to coordinate (contracts, meetings) -> ZonedDateTime
Personal alarm that should be kept in sync with the sun (e.g. go to sleep) -> LocalDateTime
What’s good example/purpose for OffsetDateTime?
Additionally, most date/time serialization formats (e.g., RFC 822, ISO 3601) only allow you to specify up to OffsetDateTime and don't provide a full timezone reference like US/Eastern.
(I’m using “UI” broadly. A user session on a UNIXy system could have an associated timezone, although such a design should allow changing the timezone without logging on and off. And this “10pm local” thing is quite different from an ordinary zoned time in that “10pm local in 10 days” does not correspond to an actual known UTC time because the local time zone may change.)
2. Government suddenly changes the law and moves the offset of whole country.
3. Contract is still valid, goods have to be delivered still at 4pm, but with new offset (so at different utc time).
(I guess timezoned time would still be better than local time, but UTC would not work here)
Exactly.
Problem solved, unless the government changes the law too little before 4pm UTC. But handling this case in software is impractical.
* The coffee shop may not be located within UTC+00:00. If you show up at UTC time 16:00+00:00, I won't be there.
* The coffee shop may not be located in your current time zone. If you show up when it is "4:00 PM" in your local time zone, I won't be there.
* The coffee shop may be located somewhere that follows Daylight Saving Time. If you show up when it is "4:00 PM" in the current UTC offset of the coffee shop, I won't be there.
* The coffee shop may currently be located somewhere that follows Daylight Saving Time, but the legislature stops following Daylight Saving Time between now and our meeting. If you show up when it is "4:00 PM" according to the predicted UTC offset of the coffee shop for the day of the meeting, rather than the actual UTC offset of the coffee shop for the day of the meeting, I won't be there.
Saying "local time" implies all of the above. It means that something is being specified according to the local convention of timekeeping.
No, it really doesn’t. Saying “4pm at the coffee shop” means that, and this is a big distinction.
If I’m in a different time zone two days before the meeting, looking at my calendar, I sure hope my calendar understands the difference. If I move my entire home outside the timezone, the appointment doesn’t magically shift an hour as a result.
And any decent time library can handle this just fine as long as you don’t use “local” time. Just specify the actual timezone!
See: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...
Actual timezone would mean "2025-01-01 16:00:00 Europe/Berlin," not just "2025-01-01 16:00:00 +01:00."
Handling that kind of change would be beyond impractical though?
Wonder if they have libraries to handle such edgecases
Some words and phrases, such as "4 pm local time", require some of their semantic meaning to be inferred from context. This doesn't mean that they are meaningless. It means that the relevant context must be provided in order to interpret the phrase. If you and I have been scheduling the coffee shop meetup, then the phrases "4pm", "4pm local time", and "4pm as measured by the applicable standards in the area of the coffee shop on the day of the meeting" are all equivalent.
> Just specify the actual timezone!
This is the problem that I pointed out. The appropriate context for "4pm local time" is "at the coffee shop". However, most calendar programs will only let you provide context such as "Eastern Standard Time". This is the wrong context altogether, and choosing it assumes that the area will have extended the duration of DST between time of scheduling and time of meeting.
This is not what the proposed LocalDateTime would do. This is a “naive” time, and those are only really useful for calendar math or when you want to apply a concrete timezone.
"Local time" is basically never "good enough", actually. At a minimum, a time as you've described should include:
- a location where you're tracking the local time
- the destination local time at that location, from which you can derive most of the timekeeping context (time zone), usually
- the current time of the thing doing the computation, in order to accurately compare device to destination time
You then use those to get a UTC time that you can use to do things like a countdown. Or you can just make assumptions about those things and accept they'll be wrong; that's allowed but it's not usually what users want given we KNOW how to give them what they want.
It means “whenever it is 4pm wherever you are”.
As in, i want my alarm to go off at 4pm everyday regardless of whether i am traveling.
Python calls it a “naive” time, it has no timezone or offset. Its just a data structure that says “4pm” rather than “4pm eastern time”
An example ive used is when a user had to specify schedules for a digital menu board system. When the user says breakfast ends at 10am, that means wherever the digital menu board is located, not “10am where i was when i set the schedule”. It also doesn’t mean “end breakfast an hour early/late when daylight savings occurs”
It makes sense in any context where you need to do something at a certain time each day, and you specifically don’t mean “do this thing exactly every 24hrs”
I think this may be the exception that proves the rule. Sure, this is a valid, if specialized, semantic use case. But you only barely need a LocalDateTime type for this. If you stick that 4pm into a local database, you want to make sure that everything, including the database, knows you’re storing hours, minutes, and seconds relative to an unspecified “local time”.
So IMO this is more of an UnspecifiedZoneTime than a LocalDateTime. (Also, it has no date portion.) It makes no sense to compare it to a UTC or other date+time.
It very well could also have a date portion.
E.g. "I want this alarm/cleanup/whatever to happen on 9am on the 1st Monday of each month" based on the timezone the user happens to be at that time - i.e. not tied to any specific timezone.
And a recurrence library probably wants to avoid libc-style “localtime” here — plumbing the concept of users in places to it seems awkward. A genuinely naive time may be better — the interface could be “calculate the next recurrence of this recurring event in this timezone,” not “here’s a recurring event with associated ‘local’ time — calculate the next occurrence given my /etc/localtime and TZ environment variable”.