Signed into law in August 2005, the federal Energy Policy Act of 2005 moved the start of DST from the the first Sunday in April to the second Sunday in March and delayed the return of standard time in the autumn by a week, to the first Sunday in November. The idea: Shifting the time change by a few weeks can save on energy use.
For IT, that means every software and hardware system relying on time stamps should now be checked, evaluated and tested -- and, if need be, patched with software updates or modified to work properly. But with a wide range of security issues, compliance requirements, spam-fighting efforts and other concerns already on their to-do lists, many IT administrators are only now evaluating what the DST change will mean and how they need to respond.
Gartner Inc. issued a statement today urging companies to take the issue seriously, saying "disruptions at an IT infrastructure and application level are likely" and "will have significant implications for organizations around the world." The Stamford, Conn.-based research firm said interruptions could affect calendaring applications, billing software and security programs as well as travel and trading schedules.
"This is a minor problem compared to the big code changes required in the recent past for issues like Y2k or the euro conversion," said Will Cappelli, an analyst at Gartner. "However, significant business damage and liabilities, as well as nuisance, could occur from applications performing their processing at the incorrect time if organizations do nothing."
In the meantime, the clock is ticking.
Complicating the effort is the fact that not all vendors have said whether and how their software and hardware might be affected. That's been one of the challenges for Rudy Ebisch, the assistant director of the infrastructure group at a large global manufacturer of home and office products, who asked that his company not be named.
With nine major software platforms to deal with, Ebisch and his staff have been working for about a month to determine what they need to do to prepare for DST. During their investigation, they found that more than 100 older, unsupported applications are based on the Java Runtime Environment (JRE), which has to be patched to properly reflect the time changes.
"There are a thousand things that are going to fall through the cracks," Ebisch said. "Everything is running JRE. It's pervasive. Who is going to look at all of that and figure out what needs to be patched?" There was stuff we knew we had to check [for JRE use], but now there's a hundred other things we have to check."
Although have posted information online about the issue, many have been mum, so Ebisch said he's reaching out to them. "I have 150 vendors. They're not going to contact me, so I'll have to contact them," he said. "We've got to come up with a comprehensive list."
While the time shift shouldn't be a major issue at his company, Ebisch said it could be critical for many other businesses, including banks, investment companies, hospitals, airlines, communications systems and utilities that have time-sensitive systems. His solution -- and his recommendation to other companies -- is to designate an IT staffer to evaluate JRE use in all applications, determine what versions are in place and decide who will oversee the various problems likely to arise.
"That's what I'm trying to do," he said. "Every day, someone brings up a new area we did not think about that has to be checked, and hopefully there is a patch."
U.S. companies in areas affected by the time change will also have to modify systems to deal with companies in U.S. territories that won't change to DST, including Hawaii, American Samoa, Guam, Puerto Rico, the U.S. Virgin Islands and much of Arizona. The change could also mean complications for multinational businesses because different timeframes for DST are used worldwide.
Although the new DST schedule begins this year, the law includes provisions that could allow it to be rolled back to the old schedule, meaning that whatever changes are made this year must be reversible.
Another IT administrator, Rob Schwartz, manager of technical support at Reading, Pa.-based Boscov's Department Store LLC, said that he began DST remediation work about four weeks ago with about six staff members looking at the issue from every angle. With an assortment of IBM AIX, Microsoft Windows and Linux servers, and virtual servers in use, Schwartz estimated that at least 600 hours will be dedicated to completing the DST work at Boscov's.
"It could easily take more than that," he said. "It's not trivial, there's no question about that, so we have to look at every system."
Schwartz said that the IT department had apparently not "been keeping up with patches as we should have," which means more work for him and his staff now. "I don't think it was really on the radar until a month ago, when someone happened to see it. We really got caught. We should have been more proactive."
Cappelli, who recently co-wrote a research report on the issue with two other Gartner analysts, said the DST changes will be a "small-to-medium problem" for most companies. "It is nowhere near as huge as Y2k potentially could have been," because no one really knew exactly how IT systems would react when the calendars switched to Jan. 1, 2000, he said. "With Y2k, it's potential apocalyptic character was that it was insidious, that we didn't know what bizarre conventions could have been inside applications."
The DST issue is different because system shutdowns and other complications are not as likely as they were during the Y2k crisis, Cappelli said. "The severity is not as profound," he said, adding that that might explain corporate sluggishness to address this year's DST change. "Many IT professionals thought they were burned by Y2k because the world didn't blow up, and it caused them to downplay the fact that some [DST] work needed to get done."
As a result, many Gartner clients are just now evaluating their IT systems. "We really watched it as a slow trickle starting in late August, starting with many financial services firms," Cappelli said. There was a noticeable jump in concern in December, and now the efforts across the industry appear to be in full-blown mode, he added.
"About 70% of the Global 2000 have some kind of activities in place, and that will increase in the next month," he said. "In December, it was about 40%. We probably caught ourselves just in time."
One problem that has cropped up often for many clients, he said, is that they are still running older operating systems such as Windows NT 4.0, which is not supported by patches from Microsoft Corp. "There's a lot more NT out there than clients thought they had," Cappelli said. "That is a headache certainly." Those users will either have to "hand-hold" their systems through the DST shift or move the operating systems to newer versions. That kind of move brings its own set of risks and challenges.
"Now is not the time to press for a major operating system upgrade," he said.
The DST implementation recommendations from Gartner include the following:
-- After applying patches or manual fixes, conduct tests to verify that the proper times and dates are produced.
-- Review all applications and their interactions with other applications for DST change compliance.
-- Check with external service providers to ensure that they are modifying their own systems to comply with the changes so your systems are not negatively affected.
-- Have IT personnel scheduled to be available during the DST change on March 11 so they can repair any problems that arise, and give them well-defined escalation procedures to deal with any circumstances.
-- IT departments should schedule twice-yearly reviews prior to DST shifts to confirm that systems are working smoothly and to correct any problems that occur.
Another analyst, David Ferris at San Francisco-based Ferris Research, said the DST preparation "shouldn't be a panic response" from IT departments. But the change still needs to be given proper attention with a full regimen of evaluations, patches and testing before the deadline arrives. "I don't think it's a massive thing. It's not going to be like the Y2k scare."