3 ms·

I completely disagree, the local time is the only useful part of ISO 8601. The big problem here is that it does not use timezones, but UTC offsets. Timezones c

by crote 3y ago

I completely disagree, the local time is the only useful part of ISO 8601. The big problem here is that it does not use timezones, but UTC offsets. Timezones can and do change their UTC offsets, completely breaking all future timestamps saved in ISO 8601-with-"timezones". "08:00 UTC-02" is ambiguous, "08:00 America/Nuuk" is not.

magicalhippo 3y ago
Fair point, but in that case it needs both. Offsets for recording historical timestamps, named zones for future time. After all, if a zone changes offset today it shouldn't change the timestamp I recorded yesterday.
- Dylan16807 3y ago
  You don't need both. Named zones can do everything that offsets can, and it's still useful to know the named zone for historical timestamps in many situations. > After all, if a zone changes offset today it shouldn't change the timestamp I recorded yesterday. That's not how named timezones work. That behavior would be bad and it would also qualify as ambiguous.
  - magicalhippo 3y ago
    How do you resolve timestamps around the time the offset changes then? Give the new offset a unique name?
    - Dylan16807 3y ago
      Time zone changes are scheduled in advance (though rarely it's not far in advance) and there is only a single rule in effect at any point in time. Half the world experiences a scheduled offset change every time summer time begins or ends. Computers can handle those fine.
      - magicalhippo 3y ago
        > Half the world experiences a scheduled offset change every time summer time begins or ends. But they do so because they record the actual offset when the time is recorded. If I send you 2023-10-29T02:15NO, how do you know if it's +01:00 or +02:00? Similarly, if Norway suddenly decided to switch their offset to be 15 minutes back, how will you handle that when reading previously recorded timestamps?
        Dylan16807 3y ago
        > If I send you 2023-10-29T02:15NO, how do you know if it's +01:00 or +02:00? I think instead you'd send a timestamp (unix or NTFS or TAI or other) annotated with "Norway", and you would not send the offset. > Similarly, if Norway suddenly decided to switch their offset to be 15 minutes back, how will you handle that when reading previously recorded timestamps? Am I that bad at explaining this? If Norway changes their offset, they will change it as of a specific moment in time. Times before that moment use the old offset, times after that moment use the new offset. The timezone database doesn't just store one or two offsets for a location, it stores every offset that has ever been used. Checking whether you're before or after 5am on Feb 29th 2024 for a 15 minute change uses the same code as checking whether you're inside any particular year's version of summer time.
        magicalhippo 3y ago
        > I think instead you'd send a timestamp (unix or NTFS or TAI or other) annotated with "Norway" This is what I attempted to write with "2023-10-29T02:15NO" (NO being Norway's country code). > Am I that bad at explaining this? Could be I'm dense, and it's not my field of expertise. Let's say Norway has decided to change it's offset from +01:00 to +01:15 at 2024-01-01T01:00:00Z. I have a process that records timestamps, and lets imagine it records them with the suggested named offsets instead of numerical offsets, in the format shown above. Later next year, you look in the logs and see 2024-01-01T02:07:00NO. How do you know which time this is in UTC? With numerical offsets this is simple, because it would either be recorded as 2024-01-01T02:07:00+01:00 or 2024-01-01T02:07:00+01:15. But when you just have NO, how to you convert the timestamp to UTC?

by crote 3y ago

magicalhippo 3y ago

Fair point, but in that case it needs both. Offsets for recording historical timestamps, named zones for future time. After all, if a zone changes offset today it shouldn't change the timestamp I recorded yesterday.

Dylan16807 3y ago
You don't need both. Named zones can do everything that offsets can, and it's still useful to know the named zone for historical timestamps in many situations. > After all, if a zone changes offset today it shouldn't change the timestamp I recorded yesterday. That's not how named timezones work. That behavior would be bad and it would also qualify as ambiguous.
- magicalhippo 3y ago
  How do you resolve timestamps around the time the offset changes then? Give the new offset a unique name?
  - Dylan16807 3y ago
    Time zone changes are scheduled in advance (though rarely it's not far in advance) and there is only a single rule in effect at any point in time. Half the world experiences a scheduled offset change every time summer time begins or ends. Computers can handle those fine.
    - magicalhippo 3y ago
      > Half the world experiences a scheduled offset change every time summer time begins or ends. But they do so because they record the actual offset when the time is recorded. If I send you 2023-10-29T02:15NO, how do you know if it's +01:00 or +02:00? Similarly, if Norway suddenly decided to switch their offset to be 15 minutes back, how will you handle that when reading previously recorded timestamps?
      - Dylan16807 3y ago
        > If I send you 2023-10-29T02:15NO, how do you know if it's +01:00 or +02:00? I think instead you'd send a timestamp (unix or NTFS or TAI or other) annotated with "Norway", and you would not send the offset. > Similarly, if Norway suddenly decided to switch their offset to be 15 minutes back, how will you handle that when reading previously recorded timestamps? Am I that bad at explaining this? If Norway changes their offset, they will change it as of a specific moment in time. Times before that moment use the old offset, times after that moment use the new offset. The timezone database doesn't just store one or two offsets for a location, it stores every offset that has ever been used. Checking whether you're before or after 5am on Feb 29th 2024 for a 15 minute change uses the same code as checking whether you're inside any particular year's version of summer time.
        magicalhippo 3y ago
        > I think instead you'd send a timestamp (unix or NTFS or TAI or other) annotated with "Norway" This is what I attempted to write with "2023-10-29T02:15NO" (NO being Norway's country code). > Am I that bad at explaining this? Could be I'm dense, and it's not my field of expertise. Let's say Norway has decided to change it's offset from +01:00 to +01:15 at 2024-01-01T01:00:00Z. I have a process that records timestamps, and lets imagine it records them with the suggested named offsets instead of numerical offsets, in the format shown above. Later next year, you look in the logs and see 2024-01-01T02:07:00NO. How do you know which time this is in UTC? With numerical offsets this is simple, because it would either be recorded as 2024-01-01T02:07:00+01:00 or 2024-01-01T02:07:00+01:15. But when you just have NO, how to you convert the timestamp to UTC?