Added a new server into the tree on April 2nd and April 1st was the originally scheduled Daylight Savings Time. One of the first things I decided to do was to run the tzupdater tool since I still had it handy.
The server I installed was NetWare 6 sp5 which runs ConsoleOne 1.3.6.e. Following TID # 3639513, I ran the command “java -jar tzupdater.jar -f -bc -v” to update the zone definitions. I received read errors on all the time zones. In the middle of these errors I aborted by hitting “Ctrl+c”. Next, I ran “java.exe -jar tzupdater.jar -t” to verify and also got a read error. Both are shown in figure 1.
When I ran the update again, it seemed to work. To reproduce this problem I removed ConsoleOne from the server and reinstalled it from the Product CD. The problem came back, but it happens on the first time I run the tzupdater only. These errors were not consistent. A few times I ran the checker after aborting the failing update and the checker ran clean, indicating no errors. But, this can’t be because I never let the update finish. This leaves me to not trust the tzupdater utility because I can’t rely on its checking capability.
To take the test further, I decided to set the server clock back to March 29th, a day before the regularly scheduled time change. The tzupdater ran without a hitch.
Running the tzupdater during the original DST dates is problematic. I ended up using the other option for the Java update JVM 1.4.2_13. The only downside here is that in order for it to take effect you’ll have to reboot the server.
Another issue, totally unrelated to DST, was if I mapped directly to the \bin directory I would get the following error message stating that the version is incorrect. It also states that it can’t find the java.dll which I verified is right in the root of that directory. I had to map to the root of SYS, then path out to the \bin directory to run the tzupdater.