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

▲

fauigerzigerk 3 days ago | parent | next [-]

If 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 3 days ago | parent | prev | next [-]

If 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.

▲

bloak 3 days ago | parent | prev | next [-]

Unless New York gets split into two, Berlin-style, and the parts have different time zones.

▲

mcny 3 days ago | parent [-]

Should 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 3 days ago \| parent [-]
		Yes? Same could be said right now for setting an alarm during the hour skipped/repeated by a DST transition.

▲

burntsushi 3 days ago | parent | prev [-]

You 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.