When Y2K came and went without a major upheaval of the world's IT infrastructure, it left a legacy of complacency that may come back to haunt IT departments when changes to daylight-saving time take effect on 11 March.
Complacency has "been the issue here, because Y2K didn't create as many issues as one would imagine, since that point in time coding has not been as rigid," said Ray Wang, a principal analyst at Forrester Research who I son eof the authors of a new report titled "Echoes of Y2K in Daylight-Saving Time Changes".
Daylight-saving time (DST) will move forward one hour on the second Sunday of March instead of the first Sunday of April, because of the US Energy Policy Act of 2005. DST will also be extended by one week in October.
Wang and co-author Jeffrey Hammond list problems the time change may cause if systems are not updated and urged IT professionals to take action.
International business systems that work across many time zones could face confusion. "One day each year will be 25 hours, and one will be 23 hours. Consequently, display and time-tracking problems remain the most significant issue," the analysts wrote.
Business applications that record transactions could be affected. Billing programs that calculate elapsed time may be at risk, particularly in industries that rely on precision time, such as transportation, financial services, telecommunications, healthcare, and high-tech manufacturing, they said.
The problems could be as small as a meeting time being an hour off, and as big as a ticketing system connected to an airline issuing tickets for the wrong time, Wang said.
"We're stuck with a situation where a lot of people haven't put together testing or patch management plans that would account for these changes automatically," he said. "There will be massive problems if people don't start thinking about it and testing to find out what those problems will be."
Forrester made the following recommendations:
- Assess the overall environment for probability and potential impact. Evaluate all combinations and configurations of software, hardware and operating systems. Also determine which business processes require time sensitivity.
- Develop action plans across the enterprise. Identify tools to be updated and which product changes must be made.
- Marshal testing and application development resources. Testing pros should run a post-patch regression on custom applications. Keep a few developers on call the week after DST changeover to fix undetected problems.
- Reach outside IT. Firms lagging behind in updates may find that employees outside IT can update machines or reset time zones if given explicit direction. Businesses should at least communicate with users about the DST issue.
- Seek changes in future contracts. Seek legal counsel on contract language that protects future investments in equipment and software.
System patches http://www.cio.co.uk/concern/change/news/index.cfm?articleid=725&pagtype=allchantopdate are required for operating systems released prior to early 2006, Forrester reported. "Patches range from automatically applied updates for recent versions of Windows and OS X to installable fix-packs for Unix, Linux , z/OS and i5/OS, to instructions and tools that detail how to manually manipulate time zone tables in older versions of Windows and Java," the researchers said.
Wang added Forrester found 33 packaged application vendors that still don't have a solution for the changes, although some of these vendors may rely on the Microsoft Windows clock, for which there are available patches. A Forrester survey of 11 application vendors found that most clients could fix the DST problem through operating system patches that address time zone change.
The report states that vendors have generally informed clients of the problem and published updates, but Wang said, "vendors haven't been as careful as they should have been".