DST will leap forward on March 11th this year. Are all your production environments patched? Brian Hayward's blog offers some last-minute advise on where to find the appropriate patches. Brian provides us with a step-by-step guide to identify all the Java installations in an environment, including old versions of Java, and a list of patch sites offered by the usual Java vendors, broken down by version. Patching the Java libraries alone may not be sufficient, however. If you have a custom application that implements its own time functions you will still need to test that it works correctly. If you used the standard Java calendar functionality these patches will solve most of the problems and all that remains for your organization is to test, test, test!
- Posted by: Eugene Ciurana
- Posted on: March 06 2007 10:59 EST
Applications that deal with dates in the future may already have problems depending on how they have stored dates. If you stored a date/time that occurs between March 11 and April 1 using an unpatched JDK then you read it back using a patched JDK it may be off by an hour because the conversion between localtime and GMT will have different offsets. Also, when patching a distributed environment, if systems are exchanging date/times between March 11 and April 1, if only one side of the exchange has been patched, it may differ by an hour.
Special concern is for the '*ST's (eg EST) on who java has been forgiving till now. The new DST patch strips out the daylight savings functionality from the EST (and some other *STs).Many have transitioned to America/NewYork more recently but many who are on EST and apply the DST patch are in for some real surprises. Thanks.
The linked article in the story is not up to date. Even if you are using a supposed "DST compliant" JDK version such as 1.5.0_10 or 1.6 you still need to apply version 1.0.1 of the Sun tzupdate tool to avoid a potential issue. Due to this subtle bug, if you try to parse a time with a three letter US daylight saving timezone acronym in a different timezone it will fail to get the value correct. For example if you try to parse "08:00 EDT" (using SimpleDateFormat for example) in any other timezone apart from America/New_York - such as America/Los_Angeles or Europe/London - it will get the value wrong - treating the time as 06:00 PDT for example rather than the correct 05:00 PDT. Sun only very recently made this known. --Robert