Comment by nullc
4 days ago
Currently a 'time' is ambiguous if it doesn't come with a timezone. And if it does come with a timezone, then there is no issue with that future shift. You wouldn't redefine EST you'd create an EST2 that was shifted (and which people would colloquially call 'Eastern' after long enough).
So the exact duration between any two times would be easily computed, so long as those times were precise enough to include their timezone-- which they have to be already.
> if it does come with a timezone, then there is no issue with that future shift.
There is no issue that didn’t already exist, but it remains true that future wall-clock times cannot be predicted with certainty, because tzdata may change between now and the future time.
When someone sets an alarm for 12:00 in five years in the current time zone, how do you store that? It can make a difference whether you store it as a Unix timestamp or as broken-down time plus time zone.
You store the future alarm as a wall clock time and date plus location, without making any assumptions about what the civil time offset is going to be on that particular date in that location. When the time comes, whatever system has to read your record and raise the alarm will know what the local time is.
tzdata routinely issues historical corrections in newer versions.
So while the political time zones don't change retroactively, the technical rules used in computers can.