26 ms·

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

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?
        Dylan16807 3y ago
        A Unix/NTFS/TAI timestamp would not be affected by the offset. Using Unix as the example: 2024-01-01T02:07:00+01:00_NO -> 1704071220_NO 2024-01-01T02:07:00+01:15_NO-> 1704070320_NO The timestamp doesn't have to be UTC, but it should specifically not be local time. You should be able to convert it to UTC without knowing the offset or time zone. So, done this way, storing time zone and no offset is unambiguous. And it gives you more information than storing an offset and no time zone.

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?
        Dylan16807 3y ago
        A Unix/NTFS/TAI timestamp would not be affected by the offset. Using Unix as the example: 2024-01-01T02:07:00+01:00_NO -> 1704071220_NO 2024-01-01T02:07:00+01:15_NO-> 1704070320_NO The timestamp doesn't have to be UTC, but it should specifically not be local time. You should be able to convert it to UTC without knowing the offset or time zone. So, done this way, storing time zone and no offset is unambiguous. And it gives you more information than storing an offset and no time zone.