We've all lived with one set of Daylight Saving Time rules since about 1986. For the last twenty years it's been "First Sunday in April" and "last Sunday in October". Now, with thanks apparently due to a U.S. Congress that felt the need to 'do something', all the rest of us have to do something with our clocks.
First, though - this only matters if you actually need to worry about what time of day it is. If your lifestyle is one that doesn't revolve around a clock, then count yourself lucky and go back to your nap. Rise with the sun, and go about your day.
For the rest of us, the new rule is "second Sunday in March" and "first Sunday in November". Sunday, March 11 will be the first time this new rule is used. The usual Daylight Savings changes apply - adjust the clocks, reset your watch. As you have probably noticed by now, many more devices now come with a clock built in. Our kitchen sports no less than seven clocks.
With the new rules, there are some new adjustments. I'll run through some of the simpler changes first, then save the big ones for the end.
The rest of the world isn't making the same changes as North America. Of course, the rest of the world didn't always use the same timezone rules in the first place. Those of you making weekly calls from North America to Europe figured that one out a long time ago.
Built-In Clocks
First, pay a little extra attention your VCR. If you either use the VCR clock just by looking at it, or if you depend on it to record programs, then you will want to be sure the clock is correct. Of course, if you don't care, then skip ahead. Most VCRs receive both time and DST information from a local station, but there is no good way to ensure that the whole clock system is operating correctly. Because the DST rules have not changed for so long, it's possible that your VCR is locked into using only the old rules. On March 11, you will want to check to make sure it changes properly, and on April 1, you will want to check to ensure it doesn't change at all. A note for the future; if you have problems this spring, you will likely have problems during the first week of November as well, and the problems will recur every year in both spring and fall. If that's the case, you may be farther ahead exploring the menus on your VCR and figuring out how to turn off the DST feature altogether; then you can just reset the clock like all the other clocks in your house.
Higher end devices - your TiVo or any other personal video recorder connected to the outside world - are more akin to networked computers than VCRs, and it is very likely that they are automatically updated. Either way, make a note to check the VCR clock both on March 11 AND April 1, to ensure it is both correct the first time and that it doesn't make an extra adjustment for you on April 1. The also applies to most newer cell phones, which get their time from the cell phone network.
Clocks in Computers
Since 1986, there has been an enormous change in the use of computers in our world. Even in 1986, some computers still needed their clock set every time you started them. Today, most computers keep a reasonably accurate clock running full time, and it's not unusual to have this clock corrected against an external source. But all this hides a nasty secret, hidden from most computer users. When your computer sets the clock against an external source, it sets "universal time", once known as Greenwich Time. This is always the same, and the dirty secret is that converting Universal time to local time is entirely the job of your local computer. It needs to know all the timezone rules - the Eastern time zone is five hours behind Universal Time - and what dates are used to convert to and from Daylight Savings Time. And because computers are used everywhere, most computers need to know the timezone and DST rules for all places in the world. The computer in front of me knows 88 different places. However, various cities, states, provinces, organizations, and other parts of the world sometimes have their own ideas about local clocks and DST; one commonly used source of such data lists 390 zones around the world.
So, if you want your computer to change to Daylight Savings at the right point in time, you will need to update all those rules. If you do anything as simple as send email from your computer, those rules should be updated. (I'm talking about YOUR computer. If this is your employers computer, they have to fix it. More about why later.) Fortunately, this isn't too hard. There are easily usable patches for most computers, even older ones, as well as for most handheld computers. I'll include some links at the bottom.
The Clock Meets The Calendar
This would almost be easy, except for one additional requirement we place on many of these computers. We expect them to accurately calculate time not just right now, but well into the future. We use calendar programs to plan out our days, into next week, next month, and next year. Suddenly, this becomes an incredibly complex problem, something to make your brain hurt when you try and figure it all out. I could write several more articles about why this has become such a tricky problem - and I'm certain someone already has written such articles - but the core of the problem is this: most calendar programs, when asked to record a meeting on Mar 12, 2007 from 9AM to 10AM, first add other information such as your timezone and timezone rules, and then convert all the dates and times to a single format - typically some form of Universal Time. Whenever you ask to see your calendar, it then reverses those steps to show you your meetings and appointments.
This would all be fine, until those rules change. International travelers who carry their laptop and change to local time have long been aware of the mayhem that can happen in their calendar programs when they change the local timezone on their computer. And these DST rule changes are exactly the type of thing to cause this problem to appear for almost everyone. When your calendar program stored "9AM" it converted it to "14:00" using the Eastern time zone rule. But rule has now changed for March 12, so when it shows you the meeting, it will now show you "10AM".
There are further problems if someone creating a meeting has one version of rules for a timezone while the person accepting the meeting has a different version of the same rules. That's why you should let your local information technology department work out this problem on your work computers. They might still get it wrong - but there is no way for you to get it right.
There ARE fixes for this, but this starts to get very tricky, very quickly. The fixes often need to make changes to your appointment schedule. If the fix isn't done carefully, it may cause appointments to move more than once. In some cases, there is no correct fix available. If you have a phone call on March 12 from London (UK) at 9AM, it will be 2PM in London. After all the changes are worked out, they will still call you at 2PM London time - but that will now be 10AM Eastern time. If you have another meeting at 10AM, then the change in rules has effectively created a scheduling conflict where one previously did not exist.
This type of problem is what separates this change from the Y2K problem. With Y2K, there was little doubt about what constituted the correct result. But with timezone rule changes, there won't always be a right answer.
In some cases, we are discovering that some software can't be updated easily. Some calendar systems have add-on components to manage rooms and other resources within a company. There may be no way to update this software's existing bookings. When that happens, the only choices are to leave the bookings as-is, meaning they appear to move in time when we change the DST rules, or to erase everything and let your users rebook all their meetings and resources for the affected time period.
How Not to Do This Again
So how did we got into this situation, and how can we avoid it in the future? This is not just idle speculation; the same act of U.S. Congress that started this also sets that it runs for three years, after which time it should be evaluated to see if they will stick with it, or revert back to the old schedule. Fun times ahead!
Most of our devices that try to understand Daylight Savings Time assume that the rules will be the same every year. This assumption is the first problem. There are systems that allow you to specify timezone rules as being different from year to year. The people using those systems made all these changes back in 2005, while those of us without them had to wait until at least late November 2006 to make these changes. Designing with the assumption that the rules will change would be a start.
The calendaring issues are somewhat different. Calendar programs generally assume they know more about time than they really do. When you made that meeting for 9AM on March 12, you didn't really mean either "Eastern Standard Time" or "Eastern Daylight Time"; you likely meant "Eastern Time", expecting to use either Standard or Daylight, whichever was in use on that day. Calendaring programs also commonly assume that an 'all day' appointment means "from midnight, to midnight". But that isn't what we want it to mean. When I say "all day on March 12", then I'm usually only looking at the calendar, not the clock. It should only start at "midnight at the start of March 12" if I actually make the effort to say exactly that. Finally, calendar programs have to avoid converting everything to Universal Time and discarding information that was only available when the appointment was created.
These Daylight Savings issues don't have the same potential for large scale problems as the Y2K issues. At the same time, there may be a great many smaller issues. Y2K could have been a mess, but we sorted out all the issues early, and anything that needed fixing was fixed. This time around, we didn't really get to it early, many of the problems don't have the clear solution of Y2K, and for some problems, there just won't be a fix.
Daylight Saving Links
Microsoft Windows and applications DST changes
-
http://support.microsoft.com/gp/cp_dst
Apple Macintosh DST changes
-
http://docs.info.apple.com/article.html?artnum=305056
Blackberry DST changes
-
http://www.blackberry.com/DST2007/patch/index2.shtml
Palm DST changes
-
http://www.palm.com/us/support/downloads/dst.html
A handy test of the Java environment in your browser
-
http://ablogofideas.net/blog/2007/02/24
A good under-the-hood explanation of Daylight Saving issues
-
http://msexchangeteam.com/archive/2006/10/17/429210.aspx