3 ms·
You are conflating two separate issues. To address your first issue, ISO 8601 uses numeric time zone offsets because it is simple and reliable. It lets you inte
by nayuki 6y ago
You are conflating two separate issues. To address your first issue, ISO 8601 uses numeric time zone offsets because it is simple and reliable. It lets you interpret a timestamp offline, without needing an enormous database of names and rules, and without constant online updates due to political reasons as you said.
Another way to think about it is like this: Suppose right now you schedule a future event that happens at exactly 2025-07-20 13:30:00 in Tokyo time. Then you calculate exactly how many seconds in the future that event is (based on Tokyo's current time zone rules, assuming no political changes), and you start an offline countdown timer that has no Internet connection and no knowledge of time zones. You can think of ISO 8601 as basically this - a way to describe absolute points in global time without references to politically motivated definitions of local time zones.
As for the second issue regarding positive/negative leap seconds, this issue is not unique to ISO 8601. It stems from UTC, and afflicts every popular system for describing time-of-day. If you want to subtract dates reliably to calculate the physical (rather than calendrical) number of seconds, you want to use TAI (Temps Atomique Internationale).
- BoppreH 6y ago> You can think of ISO 8601 as basically this - a way to describe absolute points in global time without references to politically motivated definitions of local time zones. But that's TAI. Any calendar is a consensus agreement and amenable to politics (see Samoa skipping a day in 2011 [0], and all the bizarre calendar changes of the 18th century). ISO 8601 sounds simple and reliable, but only because it refused to adopt most of the human complexity of timezones. Kinda like "extended ASCII", that allowed programmers to pretend just a little longer that all characters can fit in 8-bits. And we don't have a Unicode for dates. If Tokyo changes their DST rules or leap seconds happen, your simple and reliable offline countdown timer will be wrong. How is that acceptable for a calendar-based (i.e. human) format? Or if I'm naming my files with ISO 8601 dates and relying on lexicographic sorting (as others in this thread suggested), I'll have gaps or overlaps after DST changes. Am I crazy? I'm getting lots of disagreement, so I must be doing something wrong, but the more I think about it, the more I believe that ISO 8601 succeeded by stealthily sacrificing correctness. [0]: https://www.bbc.com/news/world-asia-16351377 https://www.bbc.com/news/world-asia-16351377
- dragonwriter 6y ago> ISO 8601 uses numeric time zone offsets because it is simple and reliable. But it isn't. It's unnecessary complexity because additional numeric zones offer no real information beyond what UTC-only provides when you want to “describe absolute points in global time without references to politically motivated definitions of local time zones.”