Will the Summer Time impact IT systems?
At first sight it may seem like no big deal: clocks will move ahead by an hour. However the potential effect of the Summer Time can be compared to that of Y2K without allowing for the same proper time to prepare.
 |
| Call centres use time based routing for calls and processes. Thus, the Summer Time may have an impact on the networking systems. |
Perhaps individuals and corporations are misjudging the effects that this might have on their systems. Due to slow acknowledgement of the problem and the posting of fixes, we’ll probably encounter more issues this time than Y2K issues in client environments.
How does this impact IT systems? Any system, program or application that depends on time may be off by an hour. This could cause people to misinterpret their schedules, scheduled backup jobs or maintenance to start/end at the wrong time or fail. Similar issues in the past have been reported on the Internet with Exchange, Blackberry, Outlook, and delegate access. There will be widespread issues with the Summer Time change if individuals and companies do not plan properly.
At first thought, it seems only calendars will be affected using client server messaging products such as: Microsoft Exchange, Lotus Notes, Novell GroupWise, and the Outlook and Blackberry clients. The change in Summer Time may also affect schedules of air flights, broadcasted TV/satellite programs from overseas channels as examples. Everything from the individual computer, operating systems, email systems, applications, java applications, network devices – switches/routers/firewalls, mobile devices, PBX phone, security systems, and even Fax machines may need a patch or a manual time change. This is not just a time change problem but a far ranging problem that could affect any application where time is critical, for instance, Microsoft Exchange, Lotus Notes and Novell GroupWise.
Devices that depend on a central time source such as mobile phones will most likely not be affected. Phones that have their own internal time clocks will probably need a patch (Blackberry, Windows Mobile phones).
Businesses, and individuals who use any hardware or software that is sensitive to date and time transactions, and utilises a local time zone, or interacts with systems that use a local time zone (versus the universal UTC time zone used for many world wide business transactions) could be impacted by these changes in Summer Time. On your typical computer server or PC, the automatic decision to change to Summer time is generally made by the underlying Operating System, such as Microsoft Windows or UNIX. However, applications often also perform date and time manipulation, and may make a similar automatic decision, or use date/time calculations in other ways.
For the average home user, the impacts are not as critical, but included events such as a TV program being recorded at the wrong time, or Internet parental blocks that limit a child’s use of the Internet after certain hours starting at the incorrect time. Some alarm panels and even bank vaults locking/unlocking times will have to be dealt with too, or some businesses may open an hour late on the first day back after the change.
Research needed in all areas
After the OS has been dealt with, each application must also be examined and tested to understand if there is date/time sensitive code within. This also applies to stand alone hardware such as network devices, routers, switches and even some alarm panels. Appropriate upgrades or patches may also be required in these instances.
Research needs to be done in all areas of an organisation to ensure that on the 26th October 2008 time is as time should be. This should include an analysis of how time related events and time manipulation occur in all hardware and software devices, software applications and the interaction between them. Just as with Y2K, each system will need to be tested to ensure it passes handling the change into and out of Summer time on the correct dates/times in years to come, as well as correctly calculating any calendar related information into the future.
Networking systems often make use of local time to mark logs, as well as to schedule certain events, such the beginning or end of a time-based access-list. Call Centres used time based routing for calls and processes.
In addition, inconsistencies between time zone definitions may impact event correlation systems as well as other management systems relating to problem escalation. Having accurately represented local time is a very big concern for most organisations. Local time may be reflected in logs and on phone displays. This is especially true of systems that require accurate time and time stamping for proper operations.
For networking systems, the clock or clock source is often derived from a trusted chronological source such as a private or public Atomic clock, often through Network Time Protocol (NTP). NTP communicates time in Coordinated Universal Time (UTC), colloquially known as GMT, and thus is not impacted. System or network administrators can use NTP to synchronise the clocks on their equipment to report time. However, NTP provides a way to synchronise clocks with a reference clock and does not inherently provide a mechanism for accommodating time zone changes and updates.
Most computer systems and networks have internal clocks to keep track of the time. Operating systems generally contain tables of time zone information and local daylight saving transition dates so that the system time can be represented correctly based on the location of the system user.
Timekeeping for computer applications and systems is typically done in Coordinated Universal Time, or UTC. UTC is a universal standard of representing time that is independent of time zones and based on the old system of deriving local time from GMT. To figure a local time, the operating system or application can take a UTC value, determine what the offset to UTC is based on the time-zone information and then make any adjustments for Daylight Saving Time.
Unfortunately there is no time zone information for Mauritius in the commonly used Microsoft Operating Systems, neither for any adjustments for Daylight Saving Time. We have to use any of the few options available on the GMT+4 time zones. It is high time, the relevant authority in Mauritius contact Microsoft to have Mauritius included in the time zone table and request provision for the daylight saving transition dates
Risks factor
Accurately tracking the local date and time can affect applications’ intended behaviour. Consider how many applications in your portfolio is time sensitive. The obvious ones involve calendaring and scheduling, but the potential exposure can go much deeper. Many transaction logs (for example, ATMs) serve as the legal record of the transactions they record; being off by an hour risks legal exposure. Batch jobs set to run at midnight will now execute an hour early and truncate the first day of 29th October 2008 by an hour - a 23-hour computer day doesn’t pass muster in a 24-hour legal world.
Logs and logging applications - Correctly handling date and time information is vital for logging used in auditing or regulatory compliance. Date and time errors might have legal consequences. E-mails that are incorrectly time-stamped or security logs that are an hour out of time could come back to haunt companies in a later audit or investigation.
Financial hours during Summer Time. From the date the Summer Time ends (29th March 2009) till the next start of Summer Time (25th October 2009) , there will be an additional hour. Imagine the effect on compound-interest calculations based on hours. Scheduling applications are at risk, including messaging applications that feature calendaring or scheduling functionality or standalone calendaring tools, even beyond personal information management applications. Scheduling systems used for system operations are scheduled to run at specific times or intervals and often must be tightly controlled.
Problems to archiving - If, for example, administrators attempt to correlate system activity to trace a security event, having uncoordinated time and date information would make determining network behaviour difficult, if not impossible.
Consumer devices - During the transition, if devices that provide date and time functionality are not updated with the correct Summer Time information, notifications and triggered events will be an hour off. Examples are Radios, mobile phones, Clock, PDAs, portable music players, programmable thermostats or Ventilation/Air-conditioning control systems, video Recorders
Attendance and Overtime – Organisations using Time Tracking and Attendance will need to prepare for the computation of one non attended hour during the transition time. How many hours will be computed by the software for Overtime hours between 12:00 AM and 5:00 AM on 26th October 2008? If it is only 4 hours, the changes should reflect on the Payslip of the employee at the end of the month.
Devices that depend on a central time source
such as mobile phones will most likely not be
affected. Phones that have their own internal
time clocks will probably need a patch
(Blackberry, Windows Mobile phones).
For many users, the Summer Time change will be a relatively minor nuisance, requiring them to manually adjust the time on their devices. For example, if you program your video recorder to record your favourite show, your machine will be off by an hour unless you manually adjust it. Some organisations might encounter confusion and a loss of productivity as the change affects scheduling and calendaring environments. For instance, if a system backup tool is set to run at specified intervals, delay of those intervals can have a cascade effect on subsequent processes. But, the most significant business implications might occur in select industries or applications in which time synchronisation is critical. Examples of this scenario range from the log applications we’ve mentioned to financial applications that use time-based calculations, such as compound-interest assessments based on hours.
Manual adjustments
Having mechanisms and solutions in place to patch the various affected platforms and coordinating the updates on them will be necessary. Users can make manual adjustments to their calendars and will probably muddle through Summer Time 2008 if left to their own devices. However, the actual economic exposure to back-office systems is largely unknown, and IT professionals should exercise due diligence as quickly as possible. IT professionals need to take a close look at their systems and applications to determine which could be off when the change occurs and then take the necessary steps to correct them.
In conclusion, it is suggested that you evaluate all time stamp sensitive systems and create a project task plan to update all affected systems, applications, and networking devices. You should warn your client base of the potential problems with calendar items and summarise the impact they may see.
Start now so there is enough time to evaluate the impacts, and get the appropriate upgrades, patches or coding changes made. Otherwise, 26th October 2008 may be a little more stressful than a typical Sunday as the way computers and other electronic devices handle dates and times could become a source of headaches.
Dave KISSOONDOYAL
