Daylight-saving time is about to leap forward to March 11 instead of what would have been the normal April 1 change, and there's a chance your in-house enterprise applications won't keep up.
Instead of moving their clocks an hour ahead on March 11, enterprise apps may fall behind or even fail. For applications and systems that work within one international time zone, this means they need to be reset to move forward an hour on the correct day and time. But for systems and apps that work across international time zones, the fix is more complicated, and they "may face considerable confusion," says Forrester Research analyst Ray Wang.
Such systems are set to have one day a year that's 25 hours long and another that's 23 hours. They typically work off Coordinated Universal Time, an international timekeeping system, similar to Greenwich Mean Time. These enterprise systems are set to make the switchover to daylight-saving time on April 1. So from March 11, when the United States makes its earlier-than-usual change, until April 1, those systems and apps will be working off incorrect times.
Many enterprise applications are custom systems developed in-house. For example, scheduling and manufacturing systems with real-time components require precise time calculations, as do applications that calculate tariff charges or service billing based on elapsed time totals. These systems "are most likely to be affected," Wang says.
Applications associated with transportation, health care, financial services, telecommunications, and manufacturing, particularly process manufacturing where chemical mixtures are pressurized or heated, rely on correct timing information to perform their tasks and can't afford to be off by even an hour. Also, server log files from which electronic events, such as financial transactions, might be reconstructed are in jeopardy of being off by an hour. For example, a system that's off by an hour would significantly affect the value of trades that a currency or commodity trader makes.
Financial services provider Capital One is ensuring that the time change doesn't affect production jobs and system transactions. It's inventorying infrastructure and identifying best practices by platform and applications. "We don't expect any disruption to our customers and associates," says Robert Turner, Capital One's senior VP of IT.
DO IT RIGHT
Developers of custom apps should know how their time functions work because the original process of building them wasn't simple. But often the original developers are long gone, and someone less familiar with the source code has to decipher how the program's date and time functions operate.
The amount of work involved depends on whether 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 says.
Testing is the other key to a successful transition, Wang says. Regression tests should be executed against the patched and updated systems to ensure that they're running as expected, he says, "especially in the case of poorly documented systems with old code."
Wang looked at 10 vendors' applications--Agresso, Epicor Software, IBM, Infor Global Solutions, Lawson, M'zoft, Oracle, Sage, SAP, and Sterling Commerce--that rely on the operating system for time information, so applying a patch to the system's time zone change section fixes the problem. Apps that depend on Oracle Application Server and Oracle databases can't rely on just an operating system change and may need patches or updates to the app server and database, Wang says. And users of pre-2007 M'zoft Outlook and M'zoft Exchange must apply manual downloads.
Source
No comments:
Post a Comment