5 ms·

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 decid

by 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.
- laut 12y ago
  Let's say the meeting is supposed to take place at 15:00 "wall time" in Sydney on March 30th. Someone changes the DST rules. The meeting still takes place at the specified time. Remember we specify the time at Australia. So far so good. Usually the time from a new update is released at least a week before the change takes place. So your software might alert you about the time on the same day or the day before of the meeting. Or even half an hour before. Do the calculations at that time of the alert with the newest timezone data. And if the software is up to date with timezone database changes, users in other time zones will be alerted about the correct time. The calculation will be made before the meeting from 15:00 Sydney to whatever other time zone someone might be in.
- philh 12y ago
  Yeah, it seems like there's no general solution to this. If I put in '10AM in Chile' for grabbing coffee with a friend, I probably want it to stay in wall time no matter what happens to the offset. If I'm making a note of a solar eclipse, I need it to stick with physical time, and if the offset changes the reported time changes. If I'm scheduling a conference call to Australia, then when the offset changes, one of us is going to have to reschedule, and my calendar can't know which. (We might both have to reschedule, if neither of us can move it by a single hour.) It might be able to say "you scheduled this at 10AM, but the DST rules changed, and that physical time is now 11AM wall time, what to do?" My Australian colleague isn't going to get that warning, unless her calendar knows that she's talking to someone in Chile, but as long as one of us knows about the problem, we should be okay. But I'm not sure I trust this to cover all bases.

by laut 12y ago

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.
laut 12y ago
Let's say the meeting is supposed to take place at 15:00 "wall time" in Sydney on March 30th. Someone changes the DST rules. The meeting still takes place at the specified time. Remember we specify the time at Australia. So far so good. Usually the time from a new update is released at least a week before the change takes place. So your software might alert you about the time on the same day or the day before of the meeting. Or even half an hour before. Do the calculations at that time of the alert with the newest timezone data. And if the software is up to date with timezone database changes, users in other time zones will be alerted about the correct time. The calculation will be made before the meeting from 15:00 Sydney to whatever other time zone someone might be in.
philh 12y ago
Yeah, it seems like there's no general solution to this. If I put in '10AM in Chile' for grabbing coffee with a friend, I probably want it to stay in wall time no matter what happens to the offset. If I'm making a note of a solar eclipse, I need it to stick with physical time, and if the offset changes the reported time changes. If I'm scheduling a conference call to Australia, then when the offset changes, one of us is going to have to reschedule, and my calendar can't know which. (We might both have to reschedule, if neither of us can move it by a single hour.) It might be able to say "you scheduled this at 10AM, but the DST rules changed, and that physical time is now 11AM wall time, what to do?" My Australian colleague isn't going to get that warning, unless her calendar knows that she's talking to someone in Chile, but as long as one of us knows about the problem, we should be okay. But I'm not sure I trust this to cover all bases.