Starting with the May 2007 issue of MSDN Magazine, I decided to try something new – the interactive editor’s note. This month, the ednote discusses Daylight Savings Time and whether it ended up having any major Y2K-like effects on developers. Did you have any problems with it? This is open for discussion here; please let us know what you think! – JT
Sometime after the New Year, we became aware of a problem that had evidently been percolating for some time. For 2007, Daylight Saving Time moved up by a few weeks.
How did this happen? DST is strange enough. For 90 years, we’ve harnessed the sun by making it rise and set an hour later for a few months at a time. The science behind this is beyond our understanding, but it seems to involve an elaborate series of levers placed in space.
Technology has advanced far enough now so that we can get an earlier start on Daylight Saving Time in the United States. The Energy Policy Act of 2005 changes DST so that it now starts in mid-March and goes through the first week of November. This has two major effects that we’re aware of. First, there was a brief period of teeth gnashing in late February as the new dates approached. Second, the sun stays out an hour later on Halloween.
Suddenly, the media picked up on the Daylight Saving Time story. Out of nowhere, it became a major item for a few days. “Will this be like the Y2K bug?” “Will your machines all seize up as the airplane you’re on falls out of the sky at 2:00 AM?” “Isn’t there anything more important we should be covering?”
Of course, there was one key difference between DST and Y2K. In 1999, almost every type of computing system was affected in some way. People were worried about financial systems, travel problems, power utilities, you name it. Lousy TV movies were made showing the worst-case millennial scenario. Camping supply stores nationwide sold Y2K survival kits, consisting of plenty of bottled water, thermal blankets, and just to be safe, anti-zombie charms.
The DST change didn’t have nearly the same downside. For three weeks, our appointment calendars would be an hour out of sync and we’d miss some meetings. The local office supply store wasn’t hawking special DST survival kits with, well, pens and printed calendars. Most systems were quietly patched through Windows Update, and that was that.
You can no doubt see the analogies with general programming we’re developing here. You can relate to the worldwide panic over Y2K seven years ago—there’s always some problem that someone coded long ago, only to have it dumped in your lap at the last moment. Much of the time, these bugs consist of more panic than actual negative effect, but they become top priority.
The changes in DST are more like the problems we face every day in programming. Daylight Saving Time isn’t a universal concept. Different countries (and even different parts of the United States) observe different DST rules. Most programs don’t include their own DST code in the first place, instead relying upon the base operating system. In fact, making coding changes to account for daylight in your program would be a classic case of planning on behavior that’s “not guaranteed in future versions.”
One of the great effects of Daylight Saving Time is that you get an extra hour of daylight to read the MSDN Magazine blog each evening. If you drop by blogs.msdn.com/msdnmagazine, you can catch the latest news from the magazine, chat with an editor or two, and discuss this month’s Editor’s Note. We’ll be doing this each month from now on, so stop by and let us know how this new DST policy has affected your work. —J.T.