« Engineering for Software Performance | Main | Cool Pictures by Satoshi Kuribayashi »

March 22, 2007

The DST Fixup

As you probably noticed, the US government decided to pull a fast one and change the start of Daylight Savings Time, moving it from the first Sunday in April to the second Sunday in March. This caused problems, particularly for calendar appointments scheduled between those two dates. So why was that?

I was discussing this in a meeting of my team the other day and people were sort of harrumphing about how silly it was that Outlook had these problems, and didn't developers know that you should just store things in UTC (aka, more or less, Greenwich Mean Time) which doesn't change to DST and etc. In fact, the Wikipedia article on Daylight Savings Time states "Some computer-based systems may require downtime or restarting when clocks shift...These problems are compounded when the DST rules themselves change, as in the Y2K7 problem" and then goes on to claim "These problems can be avoided by adopting Coordinated Universal Time (UTC), which is unaffected by DST."

Right, so the people who wrote the software must be stupid? I mean, if most of the Developer Excellence Team agrees with Wikipedia, it's not going to get much more truthy than that, is it?

Except, of course, that they were wrong (as I eventually convinced them). This is an unusual case where storing appointments times in UTC actually winds up hurting you. I'm not saying storing in UTC is bad; you want a conference call between New York and Seattle to show up at the correct local time in each place, and computers move around and all that, so storing it in UTC on the server makes sense.

For example: Consider an recurring appointment that you set up every Friday at 10 am, for 4 weeks beginning March 23 and ending April 13. Outside of DST Seattle is 8 hours behind UTC, and during DST it is 7 hours behind. So if we are a computer that thinks that the cutover is April 1, that innocuous 10 am meeting actually occurs as follows, with times expressed in UTC:

• 6 pm on March 23
• 6 pm on March 30
• 5 pm on April 6
• 5 pm on April 13

Now, if you suddenly change things so that DST starts in early March, the two meetings scheduled for March 23 and March 30 actually shift; not in local time (which is still 10 am), but in actual UTC time. They are now at 5 pm also. So while most fixes about DST simply involve modifying the mapping between UTC and local time, in this case the meeting, as viewed by an alien and/or a Londoner, has shifted its start time.

So, when the cutover to DST changed, any meeting scheduled between March 11 and March 31 would need to actually change to be an hour earlier than previously. If not, it would show up an hour later when converted back to local time on a computer that had been updated (which is actually happening; people are showing up for our classes an hour late because that is what their calendar shows). And what if you have two meetings scheduled on March 26, one by a computer that has been patched and one by a computer that has not been patched? I doubt that Exchange Server has a way for a client machine to say "I really know what I am talking about when I tell you a UTC time to schedule an appointment on." And what if the Exchange Server itself hasn't been patched?

I suppose this all could have been designed for ahead of time if computers somehow presented evidence as to how up-to-date their DST cutoff date rules were, and the server arbitrating with the latest machine winning and knowing how to patch things up between different rules. But my point is that this is really a very tricky problem, which may actually be impossible to solve perfectly without a much more complicated patch than we likely had time to do.

Posted by AdamBa at March 22, 2007 09:30 PM

Trackback Pings

TrackBack URL for this entry:
http://proudlyserving.com/cgi-bin/mt-tb.cgi/566

Comments

Posted by: Adam Barr at March 24, 2007 07:26 AM