3 ms·

OK I'm game... maybe I'll learn something > - If it was supposed to represent a meeting in Asia/Tokyo and that region changes offsets (DST or political reasons

OK I'm game... maybe I'll learn something > - If it was supposed to represent a meeting in Asia/Tokyo and that region changes offsets (DST or political reasons), we don't have enough information to update the timestamp because it could also have been Asia/Seoul or other. I don't store timestamps in ISO; I use them for communication, then parse and store them as epoch time. So if the regional offset changes, the epoch time doesn't. In theory, that epoch time is absolute and I can display it localized to anybody's preferred locale later. In that light, adding/substracting seconds is just adding/subtracting seconds, although I'm usually passing that work off to a date library, which I hope accounts for skipped seconds caused by leap seconds.... For DST shifts and leap second things, aren't certain time strings just as ambiguous with a location-based time zone as they are with an offset?

BoppreH 6y ago
> For DST shifts and leap second things, aren't certain time strings just as ambiguous with a location-based time zone as they are with an offset? Good point. I'd argue that location-based time zones make the uncertainty more explicit, but they don't remove the ambiguity. > epoch time is absolute That's a consistent approach, but is it correct? Let's say I'm today in America/New_York and I schedule a local meeting for March 15th at 13:00 (the day after Daylight Savings Time is scheduled to start). The string 2021-03-15T13:00-04:00, or its equivalent epoch time, is saved in your system. The government then decides to postpone DST by a couple of days. Your saved epoch time is now equivalent to March 15th at 14:00 in America/New_York. If you display it back to me like that, I'll complain your system corrupted my input. This can even happen to timestamps in the (recent) past, since abrupt changes can take days to propagate to user's TZ databases and lead to retroactive changes. If my meeting was stored in your system as "2021-03-15 13:00 [America/New_York]" instead, there would be no problem. The same approach works with the virtual "local" timezone, used for alarm clocks, birthdays, new year celebrations, etc, which cannot be converted to epoch time. I don't know if this is the best solution, as I've never deployed it at scale. But it sure sounds more logical to me.

BoppreH 6y ago

> For DST shifts and leap second things, aren't certain time strings just as ambiguous with a location-based time zone as they are with an offset? Good point. I'd argue that location-based time zones make the uncertainty more explicit, but they don't remove the ambiguity. > epoch time is absolute That's a consistent approach, but is it correct? Let's say I'm today in America/New_York and I schedule a local meeting for March 15th at 13:00 (the day after Daylight Savings Time is scheduled to start). The string 2021-03-15T13:00-04:00, or its equivalent epoch time, is saved in your system. The government then decides to postpone DST by a couple of days. Your saved epoch time is now equivalent to March 15th at 14:00 in America/New_York. If you display it back to me like that, I'll complain your system corrupted my input. This can even happen to timestamps in the (recent) past, since abrupt changes can take days to propagate to user's TZ databases and lead to retroactive changes. If my meeting was stored in your system as "2021-03-15 13:00 [America/New_York]" instead, there would be no problem. The same approach works with the virtual "local" timezone, used for alarm clocks, birthdays, new year celebrations, etc, which cannot be converted to epoch time. I don't know if this is the best solution, as I've never deployed it at scale. But it sure sounds more logical to me.