4 ms·

I think ISO 8601 made a big mistake by allowing timezone-less representation[1]. They should have used L for local time so it's explicit, and not allowed any ti

I think ISO 8601 made a big mistake by allowing timezone-less representation[1]. They should have used L for local time so it's explicit, and not allowed any timezone-less representation. Sure it's technically well-defined as it is, but I think it's too important not to be written out. In that case you can represent your alarm either as 08:00L if you want to wake up in the morning regardless of where you travel, or 08:00-02 for those cases where you need to stay in sync with home say. [1]: https://en.wikipedia.org/wiki/ISO_8601#Local_time_(unqualified) https://en.wikipedia.org/wiki/ISO_8601#Local_time_(unqualifi...

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.

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.