5 ms·

Don't most time zone databases store the date of rule changes? http://en.wikipedia.org/wiki/Tz_database#File_formats http://en.wikipedia.org/wiki/Tz_database#F

Don't most time zone databases store the date of rule changes? http://en.wikipedia.org/wiki/Tz_database#File_formats http://en.wikipedia.org/wiki/Tz_database#File_formats

x1798DE 12y ago
Yeah, this was always my understanding - time zones, DST participation and dates, etc all change more frequently than you'd expect, and time zone databases keep track of when things happen precisely for this reason. If that weren't happening, I think people would have found that many of their timestamps become obsolete / inaccurate relatively quickly. That said, it does tie the stability of your datetimestamp to the stability of the tz database. I think that's a pretty good bet, but it's nice to be aware of where your abstractions can leak.
stygiansonic 12y ago
That's what I thought too. Based on the discussion surrounding this example[0], I believe that's the case. Still, date/time is a tricky subject to get right. 0. http://stackoverflow.com/questions/6841333/why-is-subtracting-these-two-times-in-1927-giving-a-strange-result http://stackoverflow.com/questions/6841333/why-is-subtractin...
mark-r 12y ago
That doesn't help if you don't save the time zone rules that were in effect when you converted the original timestamp to UTC. The problem is that you've already converted to UTC using the wrong rules, so to make things right you need to unconvert then reconvert again. But there's no way to know which timestamps need correcting and which ones don't. The databases keep track of the zone changes so you can use the proper rules for conversions in the past. They don't protect you from changes in the future.
laut 12y ago
Yes. But in this case the timeline is something like this: 1) You arrange a meeting 2) Then, after you have arranged the meeting, politicians/bureaucrats decide to change the time zone rules 3) Your meeting takes place At 1) the rules are different from at 2). At 1) you cannot see into the future and anticipate how the rules will be at 2), because you don't have a time machine. So you have to be ready for it by implementing in a way that is resistant to timezone rule changes. For instance like the described solution.
- sangnoir 12y ago
  The prescribed solution does not solve for all use cases though. Imagine if the meeting included a conference call to someone in Australia. A day before the meeting, the bureaucrats change the DST rule. The meeting invite for the Australian now has incorrect time. Storing as local time will work against events applicable across timezones. The problem isn't with UTC, it is unexpected rule changes that the converting agent (software) did not predict. That logic will have to be coded in.
  - mark-r 12y ago
    Why would the time for the Australian be incorrect? If the meeting organizer is in Chile, then the meeting time would be ruled by Chile's local clock. If the rule change affects the difference between Australia and Chile, then simply loading the updated rules on both sides should readjust things automatically - if the time was stored as Chile local, not UTC.
    - dragonwriter 12y ago
      The fact that the meeting organizer in Chile does not imply that the key constraint for the meeting time was in Chile, rather than in the schedule of the Australian attendees. (Of course, its actually possible that there were essential constraints on both sides, in which case, the problem is more difficult, or that the key constraint was that the call needed to immediately precede or follow an event in a timezone different from Australia or Chile.) Really, determining the key intent here is hard, and there is no one rule that makes it painless in all cases. There are lots of different possible intents with timing, and there is no single general rule that handles all possible changes in local time rules between the time an event is scheduled and the time it occurs.
      - laut 12y ago
        If I enter "10:00 in Chile" in a calendar app I expect it to stay "10:00 in Chile". And not magically change to "11:00 in Chile". That is what the example was.

Don't most time zone databases store the date of rule changes? http://en.wikipedia.org/wiki/Tz_database#File_formats http://en.wikipedia.org/wiki/Tz_database#File_formats

x1798DE 12y ago

Yeah, this was always my understanding - time zones, DST participation and dates, etc all change more frequently than you'd expect, and time zone databases keep track of when things happen precisely for this reason. If that weren't happening, I think people would have found that many of their timestamps become obsolete / inaccurate relatively quickly. That said, it does tie the stability of your datetimestamp to the stability of the tz database. I think that's a pretty good bet, but it's nice to be aware of where your abstractions can leak.

stygiansonic 12y ago

That's what I thought too. Based on the discussion surrounding this example[0], I believe that's the case. Still, date/time is a tricky subject to get right. 0. http://stackoverflow.com/questions/6841333/why-is-subtracting-these-two-times-in-1927-giving-a-strange-result http://stackoverflow.com/questions/6841333/why-is-subtractin...

mark-r 12y ago

That doesn't help if you don't save the time zone rules that were in effect when you converted the original timestamp to UTC. The problem is that you've already converted to UTC using the wrong rules, so to make things right you need to unconvert then reconvert again. But there's no way to know which timestamps need correcting and which ones don't. The databases keep track of the zone changes so you can use the proper rules for conversions in the past. They don't protect you from changes in the future.

laut 12y ago

Yes. But in this case the timeline is something like this: 1) You arrange a meeting 2) Then, after you have arranged the meeting, politicians/bureaucrats decide to change the time zone rules 3) Your meeting takes place At 1) the rules are different from at 2). At 1) you cannot see into the future and anticipate how the rules will be at 2), because you don't have a time machine. So you have to be ready for it by implementing in a way that is resistant to timezone rule changes. For instance like the described solution.

sangnoir 12y ago
The prescribed solution does not solve for all use cases though. Imagine if the meeting included a conference call to someone in Australia. A day before the meeting, the bureaucrats change the DST rule. The meeting invite for the Australian now has incorrect time. Storing as local time will work against events applicable across timezones. The problem isn't with UTC, it is unexpected rule changes that the converting agent (software) did not predict. That logic will have to be coded in.
- mark-r 12y ago
  Why would the time for the Australian be incorrect? If the meeting organizer is in Chile, then the meeting time would be ruled by Chile's local clock. If the rule change affects the difference between Australia and Chile, then simply loading the updated rules on both sides should readjust things automatically - if the time was stored as Chile local, not UTC.
  - dragonwriter 12y ago
    The fact that the meeting organizer in Chile does not imply that the key constraint for the meeting time was in Chile, rather than in the schedule of the Australian attendees. (Of course, its actually possible that there were essential constraints on both sides, in which case, the problem is more difficult, or that the key constraint was that the call needed to immediately precede or follow an event in a timezone different from Australia or Chile.) Really, determining the key intent here is hard, and there is no one rule that makes it painless in all cases. There are lots of different possible intents with timing, and there is no single general rule that handles all possible changes in local time rules between the time an event is scheduled and the time it occurs.
    - laut 12y ago
      If I enter "10:00 in Chile" in a calendar app I expect it to stay "10:00 in Chile". And not magically change to "11:00 in Chile". That is what the example was.