UNIX for Advanced & Expert Users

Off Topic: Daylight Saving Time's Y2K7 Problem

In 2007, Daylight Saving Time will start on the second Sunday in March (March 11, 2007) instead of the first Sunday in April (April 1, 2007). Desktop OS's patch themselves all the time, so the new DST rules taking effect next year won't have much of an impact on your PC. But many systems-including routers, servers, and mobile devices-don't change often if at all. It could be a bumpy three weeks.

Problems Affecting Java Applications:

The Java Runtime Environment (JRE) stores rules about DST observance all around the globe. Older JREs will have outdated rules that will be superseded by the Energy Policy Act of 2005. As a result, applications running on an older JRE may report incorrect time from March 11, 2007 through April 2, 2007 and from October 29, 2007 through November 4, 2007.
URGENT Actions Required: Changes to Daylight Saving Time will affect IBM WebSphere Application Server and its associated Operating Systems:
Any US time zone based application which uses time will be affected, in particular during the additional weeks of extended Daylight Saving Time in March and November starting in 2007.

Is there any fixes available.

Moderator's Note: This thread is not off-topic. -- Perderabo

For Java, Sun Microsystems has released updates to the tzinfo database for their JDK/JRE for this specific issue.

http://java.sun.com/developer/techni...T_Solaris.html

Perderabo is right, this is not at all off topic. On the contrary it is a very serious problem.

My main project where I work now is to be part of the DST mitigation team. We have 4 people where it is their main job and will be adding more to help for the next couple months.

Basically, all Unix vendors have patches that need to be applied. We're going with using Sun's recommended patch bundles, AIX technology level upgrades (to AIX 5300-04-03 or 5300-05-03 depending on the HW and apps on the box), and upgrading SuSE to SLES9 service pack 3. However, if you can't upgrade your entire OS level like that there are point patches to just address DST for each as well. In addition, application and database groups are having to patch or upgrade their items as well since many of those have built-in date/time routines that won't be fixed by just fixing the OS.

I'd say if you haven't begun working on this already get going right now. This is like Y2K in that there is a hard deadline. If you're not fixed by the first weekend in March, your systems will break.

One other misconception is that some people have resisted us fixing their servers by saying who cares if the date/time is off by an hour or that we can just manually set the time on that night for each server. This may be a workaround for very small shops or very unimportant servers. But if you have any kinds of centralized logging, enterprise monitoring, audited security apps, or similar you can't get by with such a casual response. Imagine what the security auditors will say if your company gets hacked and they can't piece together what happened since the affected servers don't agree on what time it is . . . .

I live in a place that does not implement DST, though I can imagine time changes can be a highly critical issue in a computing world. I cannot realize the justifications for winding clocks every now and then (though I know the reason), twice every year. And if it is not a self-automated process, there must be people who neglect it.

And most importantly, NTP doesn't help with this unless the system clock is set to UTC and none of the processes on the system involves translation to local time from some database, which is then irrelevant. I use UTC exclusively, by the way.

Though major DST fixes are generally available, I really doubt how many people are really aware of its significance to apply them, and I have not yet mentioned those (unfortunate?) who still keeps legacy software for which updates are not available. Windows 2000 included.

We support 200+ systems here, and some of the applications are used in the affected parts of the world (primarily the US). We have a new server patchset coming up and the engineering team has put this particular patch in that patchset. That's how we are handling it.

BTW, we have a deadline for this too: 10th March 2007. No exceptions. And this comes all the way from the very top.

Public Sunsolve Document 102178: Daylight Saving Time (DST) Changes for Australia (2006), United States (2007) and Others

One more update by SUN of Firmwares.

http://sunsolve.sun.com/search/docum...=1-26-102617-1