December 4

DST2007 – Springing Ahead of Time

By Ron Woerner

In 100 days (from 12/1/06), the United States will again change our clocks and follow what is called Daylight Savings Time (DST). This is an annual event for us, so why write about it now? Turns out that this year, the switch comes three weeks earlier than usual. The shocker… are you ready? … most information systems are not ready for this change. Now, the impact from this change is nothing like what was predicted for Y2K, but it could be a headache especially if your billing systems are off or your CEO misses a meeting because the clock was off by one hour.

The United State’s Energy Policy Act of 2005 changed the rules setting when DST starts and ends. The changes were implemented as part of a federal energy conservation effort. Beginning in 2007, it requires the Daylight Savings Time start three weeks earlier (March 11, 2007 instead of April 1, 2007) and end one week later (November 4, 2007 instead of October 28, 2007) — which even leaves more daylight for Halloween 🙂

Based on the software our systems currently run, they are not prepared for DST to start early and end later. For those of us in IT, this could impact calendar & scheduling applications, date/time calculations (current & historical), transaction logging, and tariff billing applications. For non-computer systems, there are also impacts, which are discussed in David Prerau’s book, “Seize the Daylight: The Curious and Contentious Story of Daylight Savings Time”. Granted, most of the impact is minor: missed meetings, wrong time on log files, clocks off an hour, video recorders missing shows, etc. However, there is the possibility that there could be a larger impact that could cause legal issues or system down-time.

Microsoft is right on top if this issue. They have an article on it at They’ve issued patches for Windows XP and 2003 Server which will be distributed automatically next month. They are working on patches for their other supported applications. One hit against Microsoft is that they are not supporting Windows 2000 or earlier OSs. You need to apply a manual registry hack to get those fixed.

I have not researched what other companies are doing. Hopefully it’s something similar. If you’ve heard, please comment and let me know.

While it may seem far into the future, one hundred days is not much time for IT. Here are five steps you can take today to assess the impact to your business and be prepared:

1. Conduct a Business Impact Assessment (BIA) on the affect of a time change. BIAs tend to be part of business continuity planning. Depending on the size of your organization, this may be a simple project to determine what systems are susceptible and what’s the impact if the time were to be off by an hour. Understanding the impact is the first step in determining the priority;
2. Check with your suppliers, partners, and vendors for an update. If they don’t have one planned, you may need to nudge them a bit to make sure they will be ready in time for you to test their updates and apply them;
(3) Develop a strategy to distribute fixes. Once you know which systems are affected and have an understanding of what your patches and solutions are, then you can effectively plan to update your systems with the least amount of disruption. Don’t forget to include thorough testing in your strategy. For some folks, this will fit into the patch management process you already use;
(4) Be ready with a contingency plan for March 12, 2007 when some clocks are not automatically changed. The specifics of your plan will vary, based on the business you are in and the potential impact you calculated. Certainly, awareness is going to play a large part;
(5) Inform others. Spread the word. This might make for an interesting update to a newsletter, to a training program or even to a lunch and learn series (though probably not the entire series).
A little time for planning and consideration now will reduce some stress and help you move from a cycle of reaction to one of proactive effort.

By working together, we all become stronger.


You may also like

Are you using frameworks properly?

Leadership and communication are actually layers, not levels

  1. Look to Australia for some experience on dealing with a change to Daylight Savings Time. Australia extended their DST earlier this year by two weeks to accomodate the Commonwealth Games (a mini Olympics for old British Empire/Commonwealth countries). Whilst Microsoft was on the ball and had a patch out that could be applied to workstations and servers, it was mainly the Linux/Unix devices that were not able to accomodate the change in a user friendly way… some like SUN didn’t even have a patch for timezone files.

    You really need to think about every IT system… the servers and desktops are the easy fruit – obvious and easy to patch. What about your Telco Switch. Anyone in a working in a call center should pay attention to this – you don’t want your phone queues opening an hour late, or closing an hour after the last agent has already logged off. What about automated environmental controls, eg. the Air-Con system in a Lab environment? What happens if you update your timezone file, but (for whatever reason) your using a european Time Server and it keeps telling you your 1hr incorrect?

    I’m not saying its a Y2K panic… but make sure you systematically evaluate your systems… and don’t trivialize. I was working in a call center, and yes, our phones closed an hour early 🙁


Comments are closed.
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Subscribe to our newsletter now!