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@earthlink.net, jleffler@us.ibm.com 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.