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.
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:
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.
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)
Posted in Problems
Copyright 2002–2011 Artific Consulting LLC.
Unless otherwise noted, content is licensed for reuse under the Creative Commons Attribution-ShareAlike 3.0 License. Please read and understand the license before repurposing content from this site.