The Calendaring and Scheduling Consortium (CalConnect) has composed recommendations and reference links to vendor sites to aid system administrators in handling the Congressionally mandated change in Daylight Saving Time (DST). A provision of the Energy Policy Act of 2005 changed DST to begin three weeks earlier and end one week later, as of the second Sunday in March 2007.
“This modification to the DST rules is the first in 20 years, and it’s causing headaches for system administrators, because the change was rather abrupt,” notes Dave Thewlis, executive director of the Calendaring and Scheduling Consortium.
CalConnect’s members offer two recommendations:
- Apply system patches to implement the new extended DST period
- Consider whether corrections are needed to systems that store date/time values, such as calendar software or spreadsheets.
CalConnect also offers a collection of links to vendor Web pages where DST updates are discussed and patches offered.
“The change in DST rules will remind some of the Y2K problems in programs that referred to a year using two digits,” explains Joseph Jackson, Computing Services, Carnegie Mellon University, in Pittsburgh. “The impact of the DST changes should be smaller, but it is still a concern for system administrators. There may be significant impact on computer support organizations in cases where meetings in a calendar system need to be corrected manually.”'
The first issue is for systems or devices that include a date/time clock that adjusts automatically for DST. These use rules to decide when to switch from Standard to DST.
For computer devices or systems with DST-aware clocks, apply updates related to the new DST rules. This applies to workstations, servers, handheld devices, phones and embedded devices such as automatic door lock systems.
Systems that are not updated will have their clocks set one hour slow during four weeks covered by the extended DST period. Additionally, e-mail messages may have incorrect time stamps or have their time stamps incorrectly interpreted. Systems using older versions of Kerberos authentication may not work, as they require clocks to be synchronized to within a few minutes. Automated processes that run at a preset time, such as unlocking a door, may happen an hour later than expected.
The second issue is stored dates/times. Many computer systems need to represent future dates and times. There may be a need to correct some of these to accommodate the new DST rules. In particular, if the system stores the date and time as a combined value that is relative to the Coordinated Universal Time, commonly known as UTC, the data in the system may be off by an hour for the weeks that used to be in Standard time, but are now in DST.
For example, if a person in the Eastern time zone entered a repeating meeting for 9:00 am Monday, it would be stored as 14:00 UTC for weeks outside of DST and 13:00 UTC for weeks inside DST. With the onset of the 2007 DST rules, the person needs to store the meeting as 13:00 UTC in order to have it show up as 9:00 am Eastern.
Systems that store dates/times relative to the local time zone are not likely to be impacted, but products that support multiple time zones will require review. For third-party software, contact the vendor. For solutions developed in-house, look for date and time values stored as one field in a format relative to UTC.
Systems that store date/time values relative to UTC will display incorrect times within the extended DST period. This will affect events not only in 2007 but also in future years. Some calendar systems store day-long events internally as midnight to midnight records. These may get shifted by one hour during the new DST weeks, causing the events to extend into the day after they were intended to finish. Other unexpected behavior may occur with calendar systems that synchronize events between two or more types of devices, such as a computer and a smart phone.
Calendaring and Scheduling Consortium