The Backstory

One of the many provisions of the Energy Policy Act of 2005 extends Daylight Saving Time (DST) by four weeks, beginning in 2007. Starting this year, DST will begin the second week of March and end the first week in November.

Whereas this is the first modification to the DST rules in the United States in 20 years, this is not the only recent change to DST around the globe. Western Australia and Brazil also made their own adjustments to DST start and/or end dates.

Systems and applications that process dates and times will be affected by this change. Unremediated systems, applications, and/or devices could exhibit any or all of the following problems:

Appointments and reminders will appear one hour earlier than they should.
All-day events will shift and span two days because these events are associated with 24 specific hours rather than an individual date.
Systems that depend on synchronization or agreement among distributed clocks may fail or malfunction.
Automated processes which are scheduled to start and/or end at a specific time may run before and/or after the intended times. This includes not only “cron” style initiation of computer processes but also extends to automated control systems performing such tasks as locking/unlocking doors.
Timestamps on filesystems, email messages, and other objects may be incorrect, resulting in sequencing errors, difficulty searching/ comparing, audit discrepancies.
Data synchronization between devices and applications may have unintended consequences.
Clock displays could be incorrect, causing confusion in cases where the time is reflected externally.
Time/date calculations and/or comparisons may produce incorrect results.

Why is this a problem now, and whose fault is it?

Indiana, Israel, and Australia, among others, have made changes in their DST observances recently. So why all the hoopla about this DST change? Primarily two reasons:

The scope of this change is substantially larger. The population of the U.S., Canada, and Bermuda is more than ten times that of Indiana, Israel, and Australia. But perhaps more importantly, the role that the United States plays in international commerce and IT development makes this change very significant across the globe.
The aforementioned DST changes were problematic and difficult in a number of ways. DST changes are not yet an entirely solved problem in the IT world.

Remediating this problem minimally encompasses adjusting the dates/times of future events already stored in devices and/or systems, and updating the rules which these systems use for calculations involving time zones.

The internal representation used to store date/time information bears greatly on how easily or automatically already saved future events can be adjusted. Similarly, how time zone rules and calculations are implemented bears directly on how easily these rules can be updated, or whether they can be updated at all.

Additionally, mobile devices are pervasive and indispensable today, as are enterprise and web-based calendaring systems connecting people across time zones, and organizational and political boundaries. Twenty years ago these things didn’t exist or they were an inconsequential novelty. Clearly that is not the case today.

As for fault, it is simply the case that most products do not readily accommodate time zone changes in all the ways they need to. Although time zone changes used to be relatively infrequent and of relatively small scope when they did occur, the impact of such changes is certainly wider than it used to be and we may see more time zone changes in the future than we have in the recent past. Consequently, implementations need to accommodate such changes more gracefully and easily in the future.

Is this another Y2K?

Counting and accounting for time has been a problematic since people starting doing so. It manifests in different ways at different times.

George Washington was born in 1732. In 1752, the British Empire switched from the Julian to the Gregorian calendar. On the Julian calendar, George Washington was born on February 11. The switch added eleven days to the calendar, giving us the now familiar date of February 22 as Washington’s birth date.

In 1936, Boulder Dam went online, power supplied to Los Angeles changed from 50-cycle to 60-cycle current, causing the 100,000 or so electric clocks in that city to run 20% faster, thereby gaining twelve minutes every hour on Boulder Dam current. The remediation program is documented in an entertaining story in Invention & Technology Magazine.

Y2K was a set of circumstances which presented a number of real problems, accompanied by substantial hysteria and confusion. This upcoming DST change is a set of circumstances which present a number of real problems absent the hysteria, and with less confusion.

Is this a serious issue? The problem is real but the impact will vary among individuals and organizations. For at least some of those running Oracle Calendar, a very fine and popular product, it seems to be. As noted below, Outlook users will need to download and run a program to correct events already entered during the extended DST period. Some users of NetSwitcher, a very popular program among laptop users, report that their time zone unexpectedly changed from Eastern Time (GMT -5) to Brisbane (GMT +10) after installing Microsoft Hotfix KB929120 which accommodates a time zone change in Australia. Users of Microsoft OSes and calendaring products will need to apply some updates, as will users of many other OSes and calendaring products.

Background References

CalConnect, the Calendaring and Scheduling Consortium, DST information page
NPR - 'Seize the Daylight': A History of Clock Chaos
Indiana's DST change in 2006
The New Daylight Saving Time - Another Y2k?
IBM’s DST FAQ is somewhat IBM-specific but provides a lucid explanation of many of the issues

Acknowledgements

Information provided by Joseph Jackson of Computing Services at Carnegie Mellon University proved to be especially helpful in the preparation of this document.

Last modified: February 16, 2007