3 ms·

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 da

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

by sirn 6y ago

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