Earlier I wrote about the change to the Daylight Saving Time and how it could cause lots of lost time and money for IT and Dev folks (potentially offsetting any savings through energy). Well, I now have first-hand experience of how things can go awry and end up costing.
My company has a production environment that is running a combination of Windows 2000 Servers and Tomcat/Weblogic Application Servers. In preparation for the Daylight Saving Time switch, we used a utility created by Microsoft called TZedit (Google it here) which is designed to allow you to manually adjust the start and end dates for Daylight Saving Time to change the start date of DST. This worked great, or so we thought. The problem was, that on the surface, everything appeared to work fine, the Timezone and time reported by the Windows system looked correct. However, deep within the bowels of the operating system, something else was going on. When the Java Virtual Machine (JVM) used by both Tomcat and Weblogic tried to get the system time, it was mysteriously offset by 5 hours, causing any date functions within our product to be offset by 5 hours (not good when you have a time-reporting program that captures check-in times).
We were able to identify that the time was offset by writing a mini Java application that simply read the time and timezone from the system. This confirmed the issue. Therefore, we used the tried and true method to fix, reboot the server. After doing this, all dates were automagically corrected. Then came the client explanations, my wonderful job, and the data clean up for transactions that were offset, not my job, thank goodness.
If you use the Microsoft TZedit to change your Daylight Saving Time start date in preparation for the change in 2007 AND you are using a Java Virtual Machine that relies on system dates, be sure that you reboot your system immediately or right after you use the TZedit application.
So, in my mind, we are losing money with this DST change…oh well!
