System chiefs run for daylight

The experts agree: This month’s shift in the start of U.S. daylight-saving time will not be the end of the world.“It’s not going to be another Y2K,” said Bob Woolley, director of technical quality management for Lee Technologies Services Inc. of Fairfax, Va.That does not mean that network administrators will not have headaches if they are not prepared to move clocks in their applications ahead one hour at 2 a.m., March 11. The problems could range from minor inconveniences to “a little chaos.”“At worst, you might show up for a meeting an hour late” if your online calendar has not been updated, said Jason Werner, product marketing manager for Novell Inc. of Waltham, Mass.But, “at financial institutions, where large amounts of money are involved, it could be a big problem,” said John Venator, president of the Computing Technology Industry Association Inc. of Oakbrook Terrace, Ill.Organizations that process time-sensitive transactions will have to make sure their systems are synchronized with the proper local time. An hour’s difference could cost someone a large piece of change or might prevent a transaction from occurring.The size of your time-induced headache will depend largely on how current the updates are on your IT systems, the extent to which your IT systems interface with physical control systems, and the number of devices you will have to lay hands on if you have to manually adjust clocks in unsupported software.The Energy Policy Act of 2005 extended daylight-saving time throughout most of the United States and its possessions by one month. It now begins on the second Sunday in March rather than the first Sunday in April and will last until the first Sunday in November rather than the last Sunday in October.The last time daylight-saving time changed was 20 years ago, before interconnected global networks ruled our lives.“It’s a classic case of unintended consequences,” CompTIA’s Venator said of the change.Networks use Coordinated Universal Time—or Greenwich Mean Time—as an international standard, but many endpoint devices and applications maintain local time as a matter of convenience and to synchronize with functions that need to take place at specific local times. Many applications pick up the time from the operating system, but some maintain their own local time files.Local time is seasonally adjusted in much of the world, and software vendors are used to dealing with these changes.“It’s not an everyday occurrence, but it happens often enough that the major operating systems have to accommodate changes in the time zones,” said Scott Chudy, senior security architect for Dimension Data Inc. of Hauppauge, N.Y.At core, the time change issue is one of patch and configuration management. The major OS manufacturers have created patches to accommodate the U.S. daylight-saving change for supported versions of their operating systems that have been maintained to the proper upgrade level. Microsoft issued its Windows time patches in December. Applications that take their local time from updated operating systems should have no problem. ()What sets the time shift apart is that, unlike a vulnerability or a bug, it could affect all platforms, rather than a single product or vendor suite. Changes have to be made across an entire enterprise.“If you do not have good change management controls, this will be very difficult,” Chudy said. The impact of many of these systems could be trivial. But some could be serious. “It comes down to the enterprise and the applications they are running,” he said.Microsoft Corp. recently released an update for Windows through Microsoft Update to help application developers. The change could affect applications of developers using the .Net Framework who use historical time zone information or who have used Microsoft’s System.TimeZone to provide custom time zone information.Microsoft also is working on a fix for developers using Visual C++, who could find their applications affected if they use the CRT time functions or the TZ environment variable.Sun Microsystems Inc. has included current Olson time zone data in the latest update releases of the Java platform Standard Edition Development Kit and Java Runtime Environment software.This does not address problems in earlier releases, but its tzupdater tool will update time zone data without altering other system configurations and dependencies of earlier releases.Oracle said that effects of time changes would be limited in its E-Business Suite to date values containing the time component, and that in most cases it would not affect the systems or would cause only minor inconveniences.The company said that only a small number of its E-Business Suite customers would have to address the issue.Unsupported legacy systems, proprietary platforms and organizations maintained without patch and configuration management could find themselves out of sync come March 11.You could just ignore this year’s changes, and accept the fact that for three weeks this winter and one week next fall your computers and applications will be one hour off.“That’s a risk most executives and CIOs are not willing to take,” said Werner.Although a handful of operating systems command the lion’s share of the IT market, there are plenty of computers running older unsupported and proprietary software that should be dealt with.Often these are one-of-a-kind servers performing some critical service and representing a single point of failure. IT departments often are reluctant to patch or update these orphans as long as they are running smoothly.“There are a lot of legacy systems that fear has kept IT administrators from keeping up to date,” Chudy said.These problems tend to multiply for systems that are used to control physical facilities. These can include:Because these systems control or monitor physical activities, being synchronized to local time is important. Otherwise physical resources might be unexpectedly unavailable.Time stamps are particularly important on security monitoring systems and logs. Being able to tell when events occurred and in what order often is the whole point of these logs.This is the area in which Lee Technologies works, Woolley said. “We deal with the physical-infrastructure guys.”In a large enterprise with a lot of unsupported software, manually updating devices might be realistic."Sometimes you just have to punt,” Woolley said. “In some cases you might not be able to do anything about it and you just have to make note of it. The key is awareness.”As in any patch and configuration management project, the first step in making sure you are ready for daylight-saving time is to know what is on your network and understand the function and configuration of each system.Next you should prioritize these systems according to the criticality of the function being performed and the impact of a disruption.Check with the vendor to see what patches are available for adjusting the time shifts. Then comes the job of downloading, testing and deploying the patches.A patch management tool is a big help in this process, even for unsupported devices that will have to be manually reset.“You could e-mail a simple script” to reset clocks, said Novell’s Werner. But to make sure the job is done right, you need to be able to audit the changes and confirm that they took place as intended.Of course, it is a little late to begin this process.“There’s not a lot of time left,” said Chudy. “If they haven’t started by now, they’re behind the 8-ball.”On the other hand, it is not too late. “It is never too late because it will not go away,” said Werner.The problem will recur in November and then again in March 2008. This is an update that, at some point, will have to be made. n