Enterprise Applications Likely To Trip On Daylight-Saving Change Without Updates

Daylight saving is about to leap forward to March 11 instead of what would have been the normal April 1 change. There's a chance your in-house enterprise applications won't keep up.

Instead of leaping forward at the right time, they may fall behind; they may even fail. For example, a system that has to work across international time zones will have one day each year that will be 25 hours long and another that will be 23 hours, and those days change with the daylight-saving shift. "Companies, individuals and computer networks that work across multiple time zones may face considerable confusion," warns Forrester Research analyst Ray Wang in a recent report, "Echoes Of Y2K In Daylight-Saving Time Changes."

Many enterprise applications are custom systems developed in-house. Those that require precise time calculations, such as scheduling systems or manufacturing systems with real-time components, "are most likely to be affected," Wang wrote.

Many applications associated with transportation, health care, financial services, telecommunications, and manufacturing, particularly process manufacturing where mixtures of chemicals are pressurized or heated, rely on correct timing information to perform their fundamental tasks. Also, server log files from which electronic events, such as financial transactions, might be reconstructed will also tend to be off by an hour. Developers of the custom applications should know about their time functions because building them is no simple feat. Developers need to know if the date and time functions are programming language specific. C++, Visual Basic, and C# rely on the operating system's time zone tables. Object-oriented programming languages such as Java and Smalltalk depend on virtual machine-related language frameworks for time calculation, Wang said.

Not all enterprise applications require the exact time and will operate normally, even if they aren't updated for the shift in daylight-saving time. But those that engage in tariff calculation and service billing require accurate local times to figure an elapsed time total, and scheduling systems need accurate local time.

A common problem is that "developers of old code may be long gone. Development managers must find appropriate resources to perform a risk and architecture assessment" to identify where potential problems lie, Wang wrote.

Another key to successful daylight-saving transition is testing. Testers should execute regression tests against the patched and updated systems to ensure they are running as expected, "especially in the case of poorly documented systems with old code," he wrote.

Applications from 11 package vendors rely on the operating system for their time information, so applying a patch to the time zone change part of the operating system, which also deals with daylight-saving time, fixes the problem, wrote Wang. SAP, Microsoft, Lawson, Sage, Infor Global Solutions, Epicor Software, and Agresso applications rely on operating system time. Users of applications depending on Oracle Application Server and Oracle databases can't rely on just an operating system change and may have to apply patches or updates to the application server and database, Wang wrote.

Users of pre-2007 Microsoft Outlook and Microsoft Exchange must apply manual downloads, he wrote.