Changing Times

Timezones are an odd, artificial necessity in our daily lives. It used to be that you defined the day based on when the sun was directly overhead, that would be high noon, 12:00 p.m. Timezones introduced a system where the time was the same throughout a geographic region, utilizing both natural geography and political boundaries to carve out regions of time.

In the U.S. they were created out of necessity by the railroads. I'm sort of winging it here, but I imagine that in a state like Pennsylvania, natural "high noon" occurs at different "times" on either end of the state. But if you were running a train network, you need to be able to say with specificity what time the train will arrive at a given station, or at a given switch (wouldn't want a train from the west and a train from the east using a switch at the same "time").

In 2000, the government in Australia (either the state of NSW or the federal government in Canberra) decided that DST should start a month earlier for the Olympics. Noble goal, but a pain in the ass for I/T folks. Most of our server side applications were timezone neutral, if anything they assumed the timezone was GMT and then did localizations based on user profiles, of course the user profiles had the "wrong" timezone information. But client side applications depended on the operating system …some times… to determine what time zone the application was in. Now, with Windows there was an easy patch to apply to the registry to add a specific one-time timezone that was to be good solely for 2000-2001, something like Australian Daylight Savings Time Special Enhanced Year 2000 Sydney Olympic Games Edition/XP (I may exaggerate a bit). And for the most part it worked, with a few glaring problems.

Lotus Notes, Microsoft Outlook, and a number of other calendaring applications all failed miserably. Though I cannot blame them entirely. See, what happened was this: the timezone patch came out about six weeks before the start of the new, temporary, DST. The timezone patch was also only actively promoted to people in Australia.

What do you do with appointments which were made before the patch was applied, and which occur in the former AST-now-for-one-year-ADT time zone?

Luckily, for most of the weird overlap period, I was heads down working on the Olympic Games and didn't really care to have meetings or conference calls with anyone outside of Sydney, let alone Australia.

Still, there were glitches, people in the U.S. would schedule calls assuming we were on AST, when we were on ADT. Since the US was on Daylight Savings Time as well, this meant the difference between the US East Coast and Sydney was a bizarre 15 hours instead of the 14 or 16 hours we had been used to (since normally the US and Australia flipped between daylight and standard time the same weekend, at most you had a couple of days of 15 hour difference).

Still, the problem exists of: what happens to appointments you schedule for 10:00 a.m. in one time zone, and then the time zone rules change. Does the meeting get rescheduled? Depending on the application, the time of the meeting may be set to GMT (so 10:00 a.m. EST is 1500 GMT, if I now go on Daylight Savings Time early and the meeting is recorded as 1500 GMT, then it should show up on my calendar as 11:00 a.m. EDT).

This is a long rambling prelude to this note of warning and caution: with the 2005 Energy Policy Act, the U.S. Congress changed the start and end of Daylight Savings Time starting with this year, 2007. This year, DST starts on the second Sunday of March 2007, and ends on the first Sunday of November (where we had used the first Sunday of April and last Sunday of October).

The politics of Standard Time v.s. Daylight Savings Time don't particularly interest me. I'd prefer sticking to just one or the other. I actually had the pleasure of getting up in a rural area of Illinois to take the bus in the dark when I was a kid, and you know it didn't really make a difference whether we were on slow time or fast time as my Grandmother in Indiana calls it.

I'm not sure what is going to happen this go-around. I was all prepared to flame Microsoft for not including the update in Windows Update, but a comparison of my registry keys with the required keys for the timezone change implies that an update did go out at some point. I don't know about OS X and will check and update this with that information.

Microsoft actually has a nice page about this here: Preparing for daylight saving time changes in 2007. I know from past experience that it's just a tweak to the registry (though from what I can tell, the tweak has been to add a specific entry for 2007, so continuing updates may be required for 2008 and on until XP goes off-support). Microsoft's advice is to include the intended local time for meetings in the description of the appointment when sending out meeting notices in the weeks that were standard-time and are now daylight savings time (11–31 March and 29 October – 3 November).

I work with two dogs and they don't really care what time we go out for walks, but if you work with people across timezones you may want to check into this issue and how your software will handle it. Don't assume it will work because it may work absolutely 100% correctly, but you'll end up with a meeting an hour off from what time you intended it to happen.

This is the first significant nation-wide change for the U.S. and Canada since the mid-1980s, and the first to occur after widespread adoption of computer technology. Things will break. My personal opinion: a change like this should have been treated with some of the same caution as the Y2K rollover. Time zones are just as baked into applications as the used of a two digit year for dates and the assumption that a simple update to a database will address any problems is mistaken.

 

Checklist

• DST starts at 2:00 a.m. local time on 11 March 2007 (the second Sunday of March) in the time zones which observe DST in the US and Canada. It ends at 2:00 a.m. local time on the 4th November 2007 (the first Sunday of November).
• There are updates for Windows and OS X, additional links are below.
• If you have a server application which is time sensitive, make sure it has been updated with appropriate rules for the change to DST this year.
• Pay special attention to the overlap periods from 11 March through 31 March and 28 October through 3 November. If something was schedule for 10:00 a.m. local standard time, what time should that be under daylight savings time?
• Review any applications, client or server, which are extremely time sensitive.
• Be aware that hardware devices which are allegedly time zone aware may not be able to be updated to accommodate the new time zone rules.

Additional Information

• Time zone entry on Wikipedia.
• Daylight Savings Time on Wikipedia
• Time Zone database
• When Does Daylight Time Begin and End? by the U.S. Naval Observatory
• U.S. Daylight Saving Time Changes in 2007 at the Sun Developer Network
• The Energy Policy Act of 2005 at the U.S. GPO, Energy Policy Act of 2005 at Wikipedia
• Microsoft's primary page: Preparing for daylight saving time changes in 2007 and How to configure daylight saving time for the United States in 2007 at Microsoft Support
• Daylight Saving Time (DST) 2007 information for WebSphere Application Server from IBM
• Apple do not appear to have a specific page for the 2007 change but About the Mac OS X 10.4.5 Update from Apple indicates updates were pushed out for OS X 10.4. Unclear about earlier versions of OS X.

Other discussion

Here I thought I was going to be all alone in warning about this and discover the Washington Post amongst others also wrote about this issue today:

• Clocks' Early Spring Forward May Bring About a Few Falls (The Washington Post, 1 February 2007): The change takes effect this year -- on March 11 -- and it has angered airlines, delighted candy makers and sent thousands of technicians scrambling to make sure countless automated systems switch their clocks at the right moment. Unless changed by one method or another, many systems will remain programmed to read the calendar and start daylight saving time on its old date in April, not its new one in March.
• Daylight Saving Time May Bite the Out-of-Date (TidBITS 29 January 2007): Unlike other operating system vendors, including Microsoft, Red Hat, and Sun, Apple has not posted sufficient information regarding how the change in Daylight Saving Time affects their products, nor which products are patched or unpatched. (via Daring Fireball)
• Daylight saving change and computer systems (kottke.org 1 February 2007)

Posted in Problems