Home » News » Daylight Saving Extended

News

Daylight Saving Extended

15 May 2007

The government recently announced that daylight saving will be extended. The change takes effect this year; bringing daylight saving forward to start at 2am on September 30, 2007. Daylight saving will now also end later; next year it will end at 3am on April 6, 2008.

For many software systems this issue is subtle and in drawing attention to it we don’t want to over-state the problem, as perhaps it was with Y2K; the mere mention of Y2K sends shivers down the spines of many within the IT industry. However, the issue can not be ignored and requires, at a minimum, changes to the underlying operating systems (Microsoft Windows, Sun Solaris, IBM AIX, etc.) and software platforms (Java, .NET, Oracle, etc.) so that software applications continue to operate as they should.

While we may shiver at the mention of Y2K the experience should mean that the operating system and software platform is all that has to change. Y2K did this for us by teaching application programmers not to write their own date conversion routines because when it came to leap year calculations in the year 2000 many people got it wrong. The solution is to rely on operating systems and software platforms to do the job; this just moved the problem somewhere else but there are fewer operating systems and software platforms than there are applications running on top of them, plus the owners of these platforms normally have greater resources.

So, what has to be done to ensure that changes made by computer companies are reflected in the operation of your software applications?

Firstly we need the major software vendors to make the necessary changes to their operating system and software platforms. To this end the government have said that the Department of Internal Affairs would work with computer companies in updating operating systems to incorporate the time changes before the start of daylight saving. When organisations such as Microsoft and Sun Microsystems respond and provide a schedule for change a proper plan will be apparent, however the following would be a reasonable course of action to expect to take:

  • For operating systems, regular maintenance updates will ensure that patches to accommodate the change are in place before September 30, 2007;
  • For your software applications, we must either ensure that there are no proprietary daylight saving routines, or if there are, they are identified and marked for change;
  • For operating systems and software platforms, you should ideally be running on a supported release. Updating to a major release is normally not trivial so if you are on older unsupported releases then they must be identified and marked for change;
  • If you are on a supported software platform then you must apply the patch provided and schedule release into production prior to September 30, 2007; and
  • You should consider what testing you have to do. Testing will do several things:
    • it will identify proprietary daylight saving routines;
    • ensure that any changes made by either you, the operating system vendor, and/or the software platform vendor are implemented correctly; and
    • test that other unrelated changes, that may be incorporated with the daylight saving patch, do not have unforeseen consequences.

The amount of testing you do will probably depends on the risk profile of your application and how discrete the fix is; ie, if the fix is categorically, only to address daylight saving then you may be able to minimise your testing.Lastly it is worth noting, and maybe taking comfort from the fact, that the US recently went through this exact same exercise.

Read article - Computerworld Tuesday, 7 May 2007