Time Isn’t Always On Our Side in IT

Computerworld - Every once in a while, we find ourselves playing the IT version of Beat the Clock. This game involves the clocks in our computers. They always do as they’re told, but sometimes we haven’t given them enough information. Two cases in point: Y2k, and this year’s scramble to update devices that didn’t know that daylight-saving time would be instituted on March 11, three weeks earlier than the date they had been programmed to expect.

It seems like only yesterday that I was inventorying my company’s security infrastructure, contacting vendors and applying Y2k patches. On Dec. 31, 1999, while all my friends were out celebrating the new year, I was with the rest of the IT department, waiting for the clock to turn and the anticipated catastrophe. When the clock struck midnight, nothing happened. All systems were normal. We had a small office celebration (the CEO provided pizza).

This year’s DST crisis was Y2k on a smaller scale. At our company, we took a serious approach, since not only our IT systems, but also the tools that the company makes, depend on the correct time.

In the old days, systems administrators had to manually set clocks when DST arrived in the spring and when it ended in autumn. Nowadays, most modern operating systems have an internal mechanism for ensuring that the time is correct, including an automatic switch to DST. This system is called Network Time Protocol, or NTP. However, some applications don’t use the system’s internal clock for time synchronization. For example, certain versions of Sun Microsystems’ Java Runtime Environment (JRE) have their own implementation of time zones and DST rules. In some cases, we needed patches from vendors to ensure that the DST timetables were updated in specific applications. Without them, as of March 11, an application like the JRE and the Java Virtual Machine would have been out of sync with the operating system clock and other services. The results might have ranged from incorrect time stamps to application failures.

We hired a dedicated project manager for the DST job. His first step was to brainstorm with as many IT people as possible to come up with a comprehensive list of the systems that would have to be reviewed for DST compliance. Unfortunately, the company lacks a robust asset-inventory tool to track all IT assets.

Many of our Unix servers run applications that use the JRE. We had to verify that every server was DST-compliant. This included the operating system, JRE and any other third-party or custom application on the servers.