What all do I need to do in a support environment before Daylight Savings starts?

Question

Hi all,

My company is supporting the following applications for an US client:

IBM Mainframe , DB2 , Unix , Teradata , Oracle , SQL Server 2005 , Lawson

Since Daylight Savings will start by next month, I would like to know your general thoughts about what all we should be careful about so that we can avoid any bad incidents?

Thanks, Visakh

Answer 1

Daylight saving can be a bit tricky, some thoughts:

• The day on daylight saving has either 23 or 25 hours, not 24 as usual
• There is either a gap between 02:00h and 03:00h or these times appear twice

You have to always use timezones when you get data from outside, if not, you will get problems. E.g. you can not know if the sender has already changed it's daylight saving setting or not because you can't reliably know if everything works correctly on the device and in addition, most users do not change the timezone(or daylight saving flag), they change the time itself and that will run you in serious trouble. Mobile phone do sometimes not change the daylight setting themselves, the users change simply change the time from 02:00h to 03:00h both CET! Thats obviously wrong since the time itself does not change, it's the timezone! It is still 02:00h CET but 03:00h CEST.

You should probably check the products/libraries you use if they work correctly with timezone-changes.

I tested our python (with mx.DateTime) environment, if it correctly knows the timezone to be used:

test program:

from mx.DateTime import *

def f(dt):
    return dt.Format("%Y-%m-%d %H:%M %Z")

base = ISO.ParseDateTime('2009-03-29 00:00')

for i in range(10):
    test = base + i*(30*oneMinute)
    diff = test.ticks()-base.ticks()

    print "Seconds between %s and %s: %d(%d) diff=%d" % (f(base),
                                                         f(test), diff,
                                                     i*1800, i*1800-diff)

output for me (living in Germany, March 29th is daylight saving day):

$ python test.py
Seconds between 2009-03-29 00:00 CET and 2009-03-29 00:00 CET: 0(0) diff=0
Seconds between 2009-03-29 00:00 CET and 2009-03-29 00:30 CET: 1800(1800) diff=0
Seconds between 2009-03-29 00:00 CET and 2009-03-29 01:00 CET: 3600(3600) diff=0
Seconds between 2009-03-29 00:00 CET and 2009-03-29 01:30 CET: 5400(5400) diff=0
Seconds between 2009-03-29 00:00 CET and 2009-03-29 02:00 CEST: 7200(7200) diff=0
Seconds between 2009-03-29 00:00 CET and 2009-03-29 02:30 CEST: 9000(9000) diff=0
Seconds between 2009-03-29 00:00 CET and 2009-03-29 03:00 CEST: 7200(10800) diff=3600
Seconds between 2009-03-29 00:00 CET and 2009-03-29 03:30 CEST: 9000(12600) diff=3600
Seconds between 2009-03-29 00:00 CET and 2009-03-29 04:00 CEST: 10800(14400) diff=3600
Seconds between 2009-03-29 00:00 CET and 2009-03-29 04:30 CEST: 12600(16200) diff=3600

As you can see with mx.DateTime that works correctly, but there are a lot of libraries and products where that fails.