Expansion in the dates for daylight saving time, dictated by the U.S. Energy Policy Act of 2005, is shaping up to be a mini-Y2K for IT organizations and software vendors.
The Act changes the start and end dates of daylight saving time starting this year. Clocks will now spring ahead on the second Sunday of March instead of the first Sunday of April, as was done in the past. As most users know, Microsoft Windows automatically adjusts for the clock change (Microsoft has a complete list of its programs affected). In addition, many business applications that depend on an accurate rendering of local time will need to be assessed. Such applications include calender and scheduling applications, programs that calculate elapsed time (e.g. tariff calculations and service billing), and transaction logging functionality that records transactions in local time. In large shops, rolling out such changes may be no small effort, and many IT managers are not even aware of the change to daylight savings time rules.
Nevertheless, many IT executives may also be skeptical about daylight savings time changes, after what was perceived to be an over-hyped need for Y2K changes. Software developers have long been aware that daylight savings time is a common source of software bugs, and a mass change to the rules will undoubtedly cause many more such problems.
Many may be taking a wait-and-see attitude, willing to react after the fact to any problems that crop up in the production environment. For mission-critical systems, such as scheduling systems in certain industries (think transportation), such an attitude may be irresponsible. IT managers should at least take the time to evaluate the impact of any problems with the clock shifting.
Wikipedia has an entry on the Energy Policy Act of 2005.
eWeek has more on IT impact of the change in daylight savings time.
No comments:
Post a Comment