Eastern Australia: Informix Database Engine requires restart after patching the OS for Daylight Savings Extension

If you use IDS (or XPS, SE, OnLine, RedBrick, Cloudscape, ...) and
your system is based in southern or eastern Australia, you are
probably already aware that the switch from summer time back to winter
time (daylight saving to standard time) has been delayed from
2006-03-26 to 2006-04-02 because of the Commonwealth Games.

What you may not have realized is that IDS uses the local tim to
determine CURRENT (and TODAY). This is determined by the TZ variable
when the server is started.

All the major vendors have released o/s patches to modify the handling
of the revised Australian rules. Mostly, they also handle the changes
for the USA in 2007 - yes, nothing is fixed. However, even if you
patch your o/s, you will need to restart your IDS instances to take
advantage of the patch.

There's an IBM DCF available about how this affects IDS at the IBM web site:

http://www.ibm.com/support/docview.wss?fdoc=imids&rs=630&uid=swg21232846

For other products, go to www.ibm.com, (or, www.ibm.com/us) and select
"Support and Downloads"; then use the search option with 'Eastern
Australia' to see the full scope of the issue. Note that Java-based
systems need a JDK or JRE upgrade - as well as the o/s specific patch.
WebSphere (and DB2) are affected.

This problem likely applies to all systems/programs with long-running programs.

If you don't do anything between now and Sunday 2006-03-26, your IDS
systems (and other systems) will report the incorrect hour for the
week until Sunday 2006-04-02. This could be dramatically serious - or
completely trivial.

If you cannot patch the o/s, you can use complicated TZ variable
settings instead. You should validate these - they seem correct when
I work with them, but you **must** validate them for yourselves before
using them:

TZ=EST-10EST,M10.5.0/3,M4.1.0/3 # NSW, VIC, ACT, TAS
TZ=CST-9:30CST,M10.5.0/3,M4.1.0/3 # SA

As far as I can tell, Australia usually uses the same abbreviation for
both winter and summer time - which is why EST and CST repeats in
those values (the second EST corresponds to summer (daylight saving)
time; the first to winter (standard) time; for testing, the second
value was set to EDT and CDT, and EDT/CDT showed up for dates before
2006-04-02 and EST and CST for dates afterwards). The switch also
happens at 03:00 local rather than 02:00 as in Europe and North
America - hence the /3.

Finally, if you use the TZ settings, please remember to cancel them
(by restarting IDS) sometime after 2006-04-02 and before March 2007.
Otherwise, you'll have the inverse problem next year.

Have fun!

If you need more information, contact IBM Technical Support first -
but you can try asking the questions here if you can't get a good
enough answer elsewhere.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@xxxxxxxxxxxxx, jleffler@xxxxxxxxxx
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/

PS: SE, of course, is minimally affected - you restart sqlexec each
time you connect to the database. Just make sure the time zone is set
correctly, and any long running jobs are restarted.
.

Relevant Pages