Daylight Standard Time Fiasco with Java

One of the hardest things to get right in Java is to figure out which class to use when working with time and dates. You have a recipe for disaster when you mix Java dates with timezone information with energy policy and a tight schedule. The U.S. Energy Policy Act of 2005 changed the start and end dates used for the Daylight Saving Time (DST). This policy had the potential negative effect of breaking millions of desktop computers, similar to the Y2K bug.

Software updates and patches where provided by software vendors such as Microsoft and Sun with plenty of time to spare before the new DST went into effect. The Microsoft patch was available as one of the thousands of security updates that you need to run on a Windows computer every so often. The Microsoft DST update was simply an exe installer. All you had to do to install the Microsoft DST update was to run it and restart your computer. Sun provided a Timezone Updater tool to patch Java with the new timezone data. The Java Timezone Updater is a jar file that you need to run from the command prompt with a series of command options. You need to run the Java Timezone Updater for each and every JRE available on the client machine! A typical client machine will have four to five different versions of the JRE.

Earlier this year when I was writing documentation and instructions for our field engineers for the new timezone change, I knew that the Java Timezone Updater was difficult for end users, even IT professionals, to run correctly. As mentioned you needed to run the updater manually from the command prompt, for every machine, for every JRE on a given machine, and there is no validation or test to notify you of success.

Well, just last week, three months after the DST change took effect one of our clients site started reporting a bug where they select April 2007 but our date widget rolls back to March 2007. After some time of head scratching, code reviews, and debugging we still were not able to reproduce the problem. After some time, it dawned on me that this might be a DST problem and sure enough we were to reproduce the bug on an updated JRE. For some reason, not yet completely explained but most likely related to human error, a whole set of computers where not patched correctly with the Java Timezone Updater. This DST bug locked out our users at this site from key UI screens at a critical time in their work flow.

We had people at the client’s site try to update our client machines with the Timezone Updater, but the bug still keep popping up. We then thought of fixing this in code with some sort of conditional chunk of code but that is just trying to fix a bad bug caused by a bad policy decision with a bad software hack because of a bad JRE update. Since our desktop client runs on Java Web Start, we thought that the best solution was to have our Web Start client run only on a newer version of the JRE that already has the correct and current timezone data. This is not entirely the most accommodating solution for the end user because each client machine now needs to have the correct JRE installed or else our application will not start.

In the end, we went with that hack, to have our JNLP restrict the version of the JRE used on our application. But this is not the best solution, since you have to update every client machines, just the scenario that Web Start promised you would not have to do! The takeaway message from this experience is that dates in Java are hard.

Technorati Tags: , , , , , ,

Leave a Reply