4 ms·
Author here. Yes, the error was to save any other time than the local time where the meeting is supposed to take place. The point of the post was to demonstrat
by laut 12y ago
Author here. Yes, the error was to save any other time than the local time where the meeting is supposed to take place.
The point of the post was to demonstrate that when storing future events that is supposed to happen in a certain timezone, save the local time (along with timezone) instead of converting to UTC.
- padobson 12y agoWhy store the UTC offset too, then? Couldn't you get that with the timezone? Then you've got the wall time for the meeting saved, and if you need to convert it to UTC for some reason, you could do it with the most current rules for the timezone. If the offset becomes meaningless in the event of a rule change anyway, why save it when the most current rules will help you get the offset?
- laut 12y agoGood question! It is optional to store the UTC offset. The reason to store the UTC offset is to avoid ambiguity there might be when the timezone rules do not change. If the timezone rules don't change and you happen to be storing a datetime that is during changing from DST to non-DST, you specify which specific time you are talking about. In autumn, clocks could be set back from 3:00 to 2:00. 2:30 happens twice. When you schedule the time you can ask the user "2:30 summer time or 2:30 winter time"? So you only use the offset for anything in rare case there is an ambiguity (usually because of going off of DST), otherwise you just ignore it. In most cases even if the rules change like in the Chile example you would ignore it as well and use the offset provided by the timezone database.