10 ms·

I have a question for the timezone crowd: why does the ISO 8601 format include a UTC offset like "+09:00" instead of a more useful region name like "Asia/Tokyo"

I have a question for the timezone crowd: why does the ISO 8601 format include a UTC offset like "+09:00" instead of a more useful region name like "Asia/Tokyo"[0]? Take for example the timestamp "2025-07-20 13:30:00+09:00": - 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. - If a leap second is subtracted at 2025-07-20 13:30:01+09:00, we'll see that timestamp twice and it's now ambiguous which moment it refers to. - If a leap second is added at 2025-07-20 13:29:59.9+09:00, we'll never see that timestamp and now it's not a valid moment anymore. - Because of the regional offset changes and leap seconds between now and then, I can't reliably subtract that date from any other date to calculate durations. I'm struggling to think of a situation where this timestamp format is the correct one. Why don't we have "2025-07-20 13:30:00+09:00[Asia/Tokyo]" or even just "2025-07-20 13:30:00 [Asia/Tokyo]"? [0]: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

sirn 6y ago
I think because it would defeat the portability of a timestamp because Asia/Tokyo isn't constant and you cannot lookup the offset without relying on external database that takes in ("2021-02-26 18:38:00", "Asia/Tokyo") as a parameter. Offset in zoneinfo changes depending on day of a year, and sometimes even hour of a day, and the database of timezone is constantly updated (latest zoneinfo is version 2021a). So while having 2021-02-26 18:38:00 Asia/Tokyo as a timestamp would more accurately represent the time, it would create another set of issues, namely requiring a database to look it up, and requiring to keep those database in sync in all systems in the world. Having both may be redundant because in that case you can't still trust the offset. There are alternative systems such as TAI64[1] based on TAI[2] that are meant to accurately represent the moment in time without being subjected to leap second (only account them on conversion to UTC). The main issue is TAI64 is not really human readable (e.g. @4000000037c219bf2ef02e94) and would still require database of leap seconds to accurately convert back to UTC. [1]: http://cr.yp.to/libtai/tai64.html http://cr.yp.to/libtai/tai64.html [2]: https://en.m.wikipedia.org/wiki/International_Atomic_Time https://en.m.wikipedia.org/wiki/International_Atomic_Time
- BoppreH 6y ago
  I knew about TAI but TAI64 is new to me, thanks. About the TZ database, don't all date lookups require accessing it? If I schedule a meeting in Asia/Tokyo now, and the database tells me it's +09:00, I still have to remember it's Asia/Tokyo because the offset may change 5 minutes before the meeting. Analyzing the timestamp requires a TZ database, but that's calendars for you; the encoding is not going to change this. We don't actually know when the meeting will take place until it does. I'm still struggling to come up with a situation where including only the offset is the correct approach, which makes ISO 8601's decision puzzling.
  - parhamn 6y ago
    Most of the time you’d just need their current timezone offset (not location) to convert the stored offset into, no?
    - BoppreH 6y ago
      The stored offset was just my best guess for what Tokyo's offset will be at that date, according to my current TZ database. If the database changes, I have to go back and edit my timestamps (!), but I dont know which ones to edit because I didn't keep track of (1) which ones are +09:00 because of Tokyo, as opposed to Seoul, and (2) which ones were created with the old database.
  - sirn 6y ago
    I think the main usage of ISO 8601 was to represent a point in time in UTC for exchange, not a local time plus timezone. When a date such as 2021-02-26 18:38:00+0900 is provided, it did not meant 2021-02-26 18:38:00 in Asia/Tokyo, but meant 2021-02-26 09:38:00 in UTC. e.g., 09:38:00Z and 18:38:00+0900 and 16:38:00+0700 were supposed to be equivalent. In this case, timezone is external to this format and the timestamp can be calculate back to UTC without relying on zoneinfo (which is very useful for exchange). Any further conversation would be external to this format. e.g., in case of calendar, it's probably more useful to have datetime in local timezone rather than of the other party's timezone so the tuple would be (utc_time, local_tz) rather than (other_localtime, other_tz, local_tz).
kalleboo 6y ago
The tz database in itself is a massive project, that only somewhat recently (2011) started being backed by an organization (ICANN, which is not completely uncontroversial), and when ISO 8601 was created, it was still in its infancy. Additionally creating a timezone database from scratch was probably outside the scope of ISO 8601.
kerblang 6y ago
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.
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
- 6y ago

sirn 6y ago

I think because it would defeat the portability of a timestamp because Asia/Tokyo isn't constant and you cannot lookup the offset without relying on external database that takes in ("2021-02-26 18:38:00", "Asia/Tokyo") as a parameter. Offset in zoneinfo changes depending on day of a year, and sometimes even hour of a day, and the database of timezone is constantly updated (latest zoneinfo is version 2021a). So while having 2021-02-26 18:38:00 Asia/Tokyo as a timestamp would more accurately represent the time, it would create another set of issues, namely requiring a database to look it up, and requiring to keep those database in sync in all systems in the world. Having both may be redundant because in that case you can't still trust the offset. There are alternative systems such as TAI64[1] based on TAI[2] that are meant to accurately represent the moment in time without being subjected to leap second (only account them on conversion to UTC). The main issue is TAI64 is not really human readable (e.g. @4000000037c219bf2ef02e94) and would still require database of leap seconds to accurately convert back to UTC. [1]: http://cr.yp.to/libtai/tai64.html http://cr.yp.to/libtai/tai64.html [2]: https://en.m.wikipedia.org/wiki/International_Atomic_Time https://en.m.wikipedia.org/wiki/International_Atomic_Time

BoppreH 6y ago
I knew about TAI but TAI64 is new to me, thanks. About the TZ database, don't all date lookups require accessing it? If I schedule a meeting in Asia/Tokyo now, and the database tells me it's +09:00, I still have to remember it's Asia/Tokyo because the offset may change 5 minutes before the meeting. Analyzing the timestamp requires a TZ database, but that's calendars for you; the encoding is not going to change this. We don't actually know when the meeting will take place until it does. I'm still struggling to come up with a situation where including only the offset is the correct approach, which makes ISO 8601's decision puzzling.
- parhamn 6y ago
  Most of the time you’d just need their current timezone offset (not location) to convert the stored offset into, no?
  - BoppreH 6y ago
    The stored offset was just my best guess for what Tokyo's offset will be at that date, according to my current TZ database. If the database changes, I have to go back and edit my timestamps (!), but I dont know which ones to edit because I didn't keep track of (1) which ones are +09:00 because of Tokyo, as opposed to Seoul, and (2) which ones were created with the old database.
- sirn 6y ago
  I think the main usage of ISO 8601 was to represent a point in time in UTC for exchange, not a local time plus timezone. When a date such as 2021-02-26 18:38:00+0900 is provided, it did not meant 2021-02-26 18:38:00 in Asia/Tokyo, but meant 2021-02-26 09:38:00 in UTC. e.g., 09:38:00Z and 18:38:00+0900 and 16:38:00+0700 were supposed to be equivalent. In this case, timezone is external to this format and the timestamp can be calculate back to UTC without relying on zoneinfo (which is very useful for exchange). Any further conversation would be external to this format. e.g., in case of calendar, it's probably more useful to have datetime in local timezone rather than of the other party's timezone so the tuple would be (utc_time, local_tz) rather than (other_localtime, other_tz, local_tz).

kalleboo 6y ago

The tz database in itself is a massive project, that only somewhat recently (2011) started being backed by an organization (ICANN, which is not completely uncontroversial), and when ISO 8601 was created, it was still in its infancy. Additionally creating a timezone database from scratch was probably outside the scope of ISO 8601.

kerblang 6y ago

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.

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
6y ago