4 ms·
This is true when using a UTC offset as it has any potential DST already applied, so it can’t adapt to changes like that. But if you say I have an appointment
by bakje 1y ago
This is true when using a UTC offset as it has any potential DST already applied, so it can’t adapt to changes like that.
But if you say I have an appointment at 2026-09-07 15:00:00 in the timezone America/New_York I think that also accounts for future rule changes of that timezone.
I’m no expert on this matter but I believe that’s similar to how the new JS temporal API handles such things
- bloak 1y agoUnless New York gets split into two, Berlin-style, and the parts have different time zones.
- mcny 1y agoShould it ring twice if you go across the border one way? Should it not ring if you go across the border the other way?
- oasisaimlessly 1y agoYes? Same could be said right now for setting an alarm during the hour skipped/repeated by a DST transition.
- fauigerzigerk 1y agoIf the definition of timezone names can change, then the combination of a future datetime and a timezone name does not identify a point in time. Also, what if I don't know yet where I will be and I want to set a reminder for a particular date and time?
- cwillu 1y agoIf I set my cellphone alarm to go off at 6am, and it goes off at 8am instead “because it's currently 6am in new york”, the alarm clock fucked up.
- burntsushi 1y agoYou also need to record the offset with the datetime and time zone. Otherwise you won't be able to detect changes to time zone rules.