IBM Java Time Zone Update(DST Changes)
It is more than likely that your WebSphere Commerce Server is impacted by the changes to the Daylight Savings Time effective March 11, 2007. An update to your OS for DST changes is not enough in itself. IBM has alluded to the fact that the DST changes will impact the commerce server installation including version 6.0.0.1. Note that you do not have to make any changes to the Commerce Server installation itself, it is the underlying Java Run Time Environment that is impacted and need fixing. This simply means that DB2 8.2.3 and down, WebSphere Application Server 6.0.x and down, WebSphere MQ 6.0 and down are all impacted. I am not sure if there are latest fixpacks for WAS, MQ or DB2 that provided for the fixes to the DST changes.
A simple way to know if you are affected is to look at your SystemOut.log and notice that your timestamps are out of sync with the system date time. You will notice it if you tail (-f) the output of this file. That is how I found out! The worst way to find out is when your scheduler behaves erratic by running the jobs an hour earlier. To understand whether you need an update, read the guidance on updating java SDKs and JREs for DST changes. At the end of this page there is a TimeTest.jar file and instructions on using it. Run this test to find out whether your servers are impacted. If you are indeed impacted the best place to start is to to read the IBM presentation on DST changes. Very quickly you will notice that you have to use Java Time Zone Update(JTZU) utility. This document has an exhaustive explanation on how to use the utility to install updates for DST changes.
I worked with this utility on our Windows server. I downloaded and uncompressed the utility into a temporary folder. The first thing to do is to set the JAVA_HOME parameter in the jtzuenv.bat to an appropriate java home. I used {WAS_INSTALL}/java. As the IBM presentation indicates, basically there are two ways to run this JTZU utility: GUI or command line. I opted for command line and used runjtzu.bat(not runjtzu.cmd). I ran the utility from the command line in DISCOVERONLY mode by updating the jtzuenv.bat file(on windows) by setting NOGUI=true and DISCOVERONLY=true. This mode basically discovers what JREs are impacted. Make sure to update the DirectorySearch.txt file to tell JTZU what folders to search in. I just included the installation folders for my commerce, db2, mq and websphere appserver install folders. This process creates a SDKlist.txt file.
I ran the utility after setting DISCOVERONLY=false in the jtzuenv.bat and running the runjtzu.bat. It is important to read the warning sign carefully and see if you should really run the utility. Basically what this means is if you apply any fixpacks that are down level and therefore do not include the DST changes updates in the fixpacks, then you will lose the changes made by the JTZU utility and that you have to rerun the utility. Finally I ran the utility with not many issues - there was one ClassNotFoundException on updating {WCS_Install}java\jre. But when I ran the utility again this exception did not appear again! To know how the update worked take a look at the LogFile.log file. This took care of my DST changes problem and my SystemOut.log file now shows the correct date time.!
Incidentally I did not have to make any changes to my WCS toolkit for development. Not sure why! What is your experience?