Did you catch that last sentence? There is a good chance this will be just another anomaly in the short but convoluted and complex history of daylight saving time. A one-off for 2007 only. So, maybe we really should be thinking about work-arounds for 2007 instead of permanent fixes.

DST Is Evil

I do have a problem with daylight saving time, though not for the usual reasons. Not because it isn't God's Time nor because it is unnecessary government interference in my personal freedom nor because I am a nasty old man.

My problem has to do with my small collection of digital watches. I have a half-dozen different sports watches: heart-rate watches, GPS watches, running watches, biking watches, etc.–all of which require nonstandard, arcane, and undocumented methods to reset the time.

Then there is the matter of automobile clocks. I used to have a very expensive German car that absolutely defied my ability to reset the digital device. My wife's car has an analog clock (yes, it is a fairly new model) with a thumbscrew that can be turned only with a pair of 16-inch vice grips.

Back to the DST Bug

You can see I was predisposed to react negatively to another daylight saving time issue–particularly one I might need to deal with in my professional life. So, before I consulted any software vendors, I engaged in a little rational thought.

There are two classes of software we need to deal with: operating systems and applications. Operating systems should pose no real problems in and of themselves. There is nothing about an operating system itself that is dependent upon any particular time convention. In fact, let's dispense with the idea there is anything particularly real about time. The special theory of relativity proposed by Einstein in 1905 did away with that notion.

The human race more or less collectively has agreed a time standard is useful for determining the relative sequence or simultaneity of events. That standard is known as Coordinated Universal Time, or UTC. The baseline for time calculations historically has been the time at the prime meridian (the meridian where longitude is defined to be 0 degrees), which runs through Greenwich, England, and is known as Greenwich mean time (GMT) or Zulu time. Time zones around the world are expressed as positive or negative offsets from GMT. I am in the Eastern time zone of the United States (GMT – 5), so the IIS log I am looking at for today starts at local midnight, but the time of the first entry for today is 05:00:00 (Zulu).

Is It Real, or Is It UTC?

For the sake of examining the DST bug, we will start with the assumption UTC is “real” time, and any foolishness having to do with time zone changes is not. In fact, operating systems–and for that matter, any serious application–is going to use UTC for internal processing. Early personal computers had a number of different methods for tracking machine time or computer time. I believe some, such as the first Apple II, did not even have a clock. Nevertheless, the systems we are concerned with today all can be considered to have an awareness of “correct” UTC; whether that comes from an internal oscillator powered by a lithium battery or a network reference device is irrelevant.

If we look at the first layer of applications that run on top of our base operating systems–things such as event timers, backup software, i/o devices, peripherals, etc.–we do see a few things that could be affected by time. There are a host of basic functionality or hotel services provided by operating systems. But I fail to see anything that looks as if it would be critically affected by an incorrect local time setting.

Some reports I have read claim backups will fail if we don't properly patch our machines. Really? I don't understand. Even if I fail to modify a machine to reflect the new DST, my backups still will run. All scheduled events still will fire. It simply means for three weeks my 1 a.m. backup will fire off at 2 a.m. local. What is the harm in that?

There are, of course, situations in which we could create confusion if we aren't consistently doing something about local time changes. Imagine a load balanced four server farm, in which two servers are patched and two aren't. So, two logs would be starting the day at 5:00 Z, and the others at 6:00 Z. In this unlikely situation, everything would work correctly, but when we analyze our logs, we would be confronted with various possible anomalies that may provide less-than-perfect traffic analysis.

Applications

The real possibilities for problems that may arise from DST changes are in applications. If you create or support airline-scheduling software, then you have been aware of the DST bug for at least 18 months and aren't even reading this article. There are three types of applications for the rest of us to consider:

o Time-agnostic applications

o Applications with their own internal clocks

o Applications that rely on the host operating system for time information

There also are two other categories to consider:

o Applications provided by outside vendors

o Home-grown applications

No Brainer

Most productivity applications rely on the host operating system for time. Your word processing software obtains current date and time information from the OS–not from itself. Date.Time.Now (or whatever code your programming language of choice uses) fetches that information from the OS. If the operating system is wrong, the application will be wrong. No big deal. So, the bottom line is for most of the tools our information workers use on a day-to-day basis, we can avoid any problem by applying either the client or server system fixes or patches provided by the vendor.

If you are open source, you can take your pick of fixes or write your own.

Create Your Own Patch

If you doubt operating systems don't concern themselves with time zones, take a look at the Windows registry key KEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTime Zones. My XP laptop lists some 64 different time zones I apparently need to be aware of, including Tasmania and Tongo. If you want to roll out your own patch, check out HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTimeZoneInformation. From there, you can modify the keys DaylightStart and StandardStart to any dates you want, including the federally mandated ones. Be careful: The dates are in hex (actually, REG_BINARY), so you might need to do a little research.

Did You Buy It?

Applications that rely on an internal clock and that were obtained from a vendor should and will be patched. Tools such as Microsoft Outlook and Lotus Notes use UTC internally, and patches are available. These guys have been dealing with world time zones and localized time differences forever. This is routine for them. What you need to do is examine your software inventory and get off a note or e-mail to all vendors asking specifically what issues they foresee and how they intend to deal with them. Don't go off the deep end and pull out your Y2K software questionnaires and change Y2K to DST and blast them out. No one willingly is going to repeat that exercise. I remember having to fill out endless Y2K documents for applications we didn't even sell anymore. I took a quick look at the Microsoft Web site to see which products are affected. Here is the list:

Windows Client, Windows Server, Windows Mobile, Microsoft Windows SharePoint Services, Microsoft Exchange Server, Microsoft Office Outlook, Microsoft Office Live Meeting, Microsoft Dynamics CRM, Microsoft SQL Server Notification Services, and Microsoft Entourage.

Just about what you would expect. Instructions and patches are readily available. IBM has a nice concise site that provides explicit and simple instructions for preparing Lotus Notes and Domino for DST 2007. All major software vendors have this thing covered.

Home-grown?

Chances are most policy admin, billing, accounting, and financial packages you are running are built on a montage of third-party applications, custom applications, and custom modifications to make them all work together. Prudence dictates you will need to examine those systems closely to see what the possible implications are. Reality dictates the implications can't be too severe. Your systems have been working in an environment where local time changes twice a year (at least). All we are dealing with is a difference in when those changes occur. And that should not cause your world to come crashing down.

I suspect some meetings will be mis-scheduled. I suspect minor glitches will occur in mid-March 2007. I suspect people may even miss a flight or two. I don't expect planes to fall from the sky or policies to be cancelled or claims to be refused over DST glitches. Take a look at your systems. Inventory your software. Ask a few questions. Apply your patches. Call me in the morning.

I Don't Have Time for This

The change to daylight saving time in the United States in 2007 is a human convention placed on another human convention. We shouldn't expect computer systems to react immediately to this sort of thing. Human engineering issues do not necessarily translate directly to computer engineering systems. It makes sense for all applications to base their clock on the time provided by the operating system. How that translates to assumed local time is not always obvious. March 11, 2007, will come and go, and the world as we know it will not end. I know I will be safe in my bed and sleeping soundly when the clocks roll back or forward. I hope you are, too. TD