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

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