I know it's a little late but here's my 2-cents anyway.
Yes, you should run DSTSHIFT.NLM on each server's console (or schedule it with the Remote Manager). If it gives you any problems, check the Time Zone SET parameter. If that doesn't help then check the log file, DSTLOG.TXT, which it creates in the same folder as the NLM.
Yes, you should run TzUpdater to update the NetWare Java Runtime Environment (JRE). OR you can try this alternate method suggested by Novell: (
Manually updating JVM time zone data on NetWare servers with JVM 1.4.x
Sun Microsystems Inc. has made a time zone updater tool available that can be used to manually update the existing time zone data on NetWare 6.5 and 6.0 servers running a JVM 1.4.x. This tool will only work with JVM 1.4.x
The following link documents this utility and provides a link to the Sun Java SE download site to obtain the utility:
http://java.sun.com/javase/tzupdater_README.html 1. download and extract the tool to a temporary directory
2. copy the tzupdater.jar file to a temporary directory on the SYS: volume of the NetWare 6.5 server
eg: sys:\temp\tzupdater.jar
3. update the current time zone information with the utility by entering the following at the server console prompt
java -jar /temp/tzupdater.jar -u -bc -v
If you have previously run this tool against Java, use the following command
java -jar /temp/tzupdater.jar -f -bc -v
4. check the results on the logger screen, which should be similar to the following:
java.home: SYS:\JAVA
java.vendor: Sun Microsystems Inc.
java.version: 1.4.2_09
JRE time zone data version: tzdata2003a
Embeded time zone data version: tzdata2006p
Extracting files... done.
Renaming directories... done.
Validating the new time zone data... done.
Time zone data update is complete.
java: Class /temp/tzupdater.jar exited successfully
5. Delete 3 files: EST, MST and HST, all contained in the SYS:\java\lib\zi directory. This is due to the bug found by SUN, referenced here:
http://sunsolve.sun.com/search/document.do?assetkey=1-26-102836-1 An optional step prior to actually updating the time zone data would be to execute the "test" option of the utility (java -jar /temp/tzupdater.jar -t -v). This will generate lots of error messages in the logger screen indicating that time zones were not found or that a test failed. This is normal and expected.
This utility will create a new time zone information directory structure for Java which will take up about 1.7 MB of actual disk space. The existing directory will be renamed so a back out option does exist if needed. The existing time zone data directory will be renamed to sys:\java\lib\zi.tzdata2003a and the new directory will be sys:\java\lib\zi.The old directory can be deleted at a later time if desired to free up a bit of disk space.
For legit Windows XP or later PCs, you can get the DST patch from Windows Update or the Microsoft Download Center. For earlier versions of Windows you'll need to make the registry changes yourself OR use one of the many UNOFFICIAL patches - BOTH can be found with a quick Google search...BUT I HIGHLY suggest that you test the START and END dates and times and a test system (or a virtual machine) before deploying on your network.
I don't know if it'll help, but when I made the registry changes (Yes, I did it myself), switch to a different time zone, "Apply" the change, change back to my time zone (PST) and then "Apply" again to see the effect.
Pages: 1
Daylight Saving Time (Read 1483 times)
