Chicago (IL) - Applying the Daylight Savings Time to a single PC isn't such a big deal, but it has been discussed as a big event in the industry. When the event shifted the clocks one hour forward on the morning of March 11, the day passed as expected: A few hiccups here and there, but important systems such as the utility grid or banking continued to ditch a Y2K type of bullet. But it isn't over yet.
For Information Technology managers in many organizations, the Daylight Savings Time DST) event in fact has been difficult as different devices are impacted in different ways. Multiply your private cellphone, your home PC and your PDA by 1000 and it becomes clear that even smaller corporations had a major event to deal with that easily could have been and, as we hear, was underestimated in many places.
Besides showing simply the time in your taskbar, computer-driven clocks provide the value of time-stamping for most IT related transactions, manufacturing operations and computing events. You can see this concept, for example in the Event Viewer on your PC: A timestamp is tied to each event and for the business world this means that a timestamp is created when a banking transaction occurs or a widget is produced. There are help desks, quality applications and many internal corporate applications that use the timestamp for searching or indexing computer databases. In this perspective, the time stamp and the need for using a correct time on a computing device becomes critical - critical enough so that American enterprises have devoted time to evaluate and resolve the DST issue.
But we are past that now. Or are we?
In fact, some may be not. We heard about some update strategies in corporations that actually are flawed and could pose a significant risk: Instead of patching the DST issue on servers, PCs and other computing devices, some corporations simply updated the time on their devices manually.
However, when a computer or control device with an embedded DST update program is reset manually, it must be reset back again on April 9 - the day when the DST normally would reset the system. Most computers and computer driven devices with an embedded clock have automatic DST update applications built in and therefore are DST enabled. The problem, of course, is that these clocks were set to update in April, not on March 11.
The prescribed fix for the DST issue involves system patches issued by Microsoft, Apple, Blackberry, HP, IBM, Sun, Oracle, Cisco, Palm, cellphone makers, among others. Larger enterprises use Time Synchronization Services; using the network to synchronize to a central time service. Users who employed these patches and methods should be safe. However, on systems where the clock was advanced manually, clock will be advanced incorrectly in two and a half weeks. But for dozens or perhaps even hundreds or thousands of systems, this approach is not only prone to errors, but can also consume lots of time and can get very expensive.
This strategy of a manual reset is routinely used for those computers and devices which have no resolution with the other methods. An exceptional update of the time could be applied where the DST patching was omitted or forgotten, or a mobile device was changed. Perhaps this device was not convenient to be patched or it may be involved in a 24x7 production, like a plant floor machine interface.
Global calendars also need to be considered when it comes to the DST issue: For appointments that were set for example for 9 am on an U.S. calendar last month to call or meet in Europe, there is the question whether the patch was applied or not. U.S. calendar changed, but the European calendar or your counterpart may not. It's best to confirm appointments in such a case.