4 ms·

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,

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

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