As you know, the daylight saving policy has been changed in Russia, effective from September 1st 2011. New time zones and DST rules have been established within the Russian regions; Moscow will use UTC+4 all year round, and all other Russian regions will keep current Summer time all year round (see http://www.government.ru/gov/results/16355/)
Among other Novell software that deals with time zones and calendars, this change affects the NetWare OS and its components. In particular, Java Runtime Environment and software that uses JRE (like iManager, ZENworks Server Management) are affected.
Ignoring this fact, and leaving NetWare and JRE time settings untouched, could lead to undesirable results such as time synchronization malfunction. For banking or large enterprise environment such issues could be critical and unacceptable.
NetWare administrators must have made Time Zone changes on their servers before the 30th Oct (Last October Sunday) to avoid incorrect time appearing on NetWare servers and connected Windows workstations (actually the summer time would be set to ‘Off’, so local time would be erroneously set one hour behind the correct time).
Preparing clients’ workstations
Don’t forget to install the latest Windows hotfixes that reflect Time Zone changes in Russia. For Windows XP it is WindowsXP-KB2570791-x86-ENU.exe (if your Windows language is English).
Updating Time Zone configuration on the NetWare OS
The main aim while changing time zone settings on NetWare server is to keep the UTC time calculated on the server unchanged. This is crucial for eDirectory health.
To check how your changes affect the current system time, you should use the TIME command before and after the changes have been made.
- Enter the console command TIME. Note the result:
Figure 1 – TIME: old time zone configuration
- Modify AUTOEXEC.NCF.SET Daylight Savings Time Offset = 0:00:00
SET Start Of Daylight Savings Time =
SET End Of Daylight Savings Time =
#SET Time Zone = EAT-3EATD
SET Time Zone = MSK-4
Time Zone format is well described on Novell support site (see http://support.novell.com/techcenter/articles/ana19931101.html).
Time zone abbreviations can be any abbreviation as you prefer. As for the number after the minus sign, you should increase it by 1 in all Russian time zones. Summer time zone abbreviations after the number should be removed as unnecessary.
For example, in Moscow region the Time Zone variable might be changed from EAT-3EATD to MSK-4.
- If you:
- can reboot the server now and
- do not use Java applications on NetWare, or don’t care about JRE internal time,
please reboot the server at this point. It is necessary to apply changes made in the AUTOEXEC.NCF. After the server has restarted, enter the TIME command and ensure that:
- Time Zone has changed,
- summer time (DST) is set to OFF,
- UTC time remains continuous,
- the difference between UTC and local time remains the same (see picture below).
Figure 2 – TIME: new time zone configuration, server is restarted
At this step, Time Zone modifications for your server have complete.
- If you can’t reboot the server immediately for some reason, you might apply time zone changes manually with a minor drawback (see later). Using any way you prefer (server console, NCF-file, MONITOR utility, NRM) you just should change appropriately the four system variables mentioned in the paragraph #2 above. 4. I used MONITOR.NLM utility and made changes in the following order:Daylight Savings Time Offset = 0:00:00
Time Zone = MSK-4
End Of Daylight Savings Time =
Start Of Daylight Savings Time =
Having completed manual configuration you will get a result like this:
Figure 3 – TIME: new time zone configuration, server is not restarted
As you can see, UTC and local time are correct, but because summer time zone abbreviation is empty, and DST status is still ON, the DST time zone abbreviation is undefined and shown as a <?>. You are unlikely to face with serious issues as a result, but to be perfect it would be better to reboot when possible. Reloading XNTPD/TIMESYNC does not help it this case. Unfortunately the only way to get DST status changed to OFF is to reboot the server.
Updating Time Zone configuration in JRE on NetWare OS
The Java Runtime Environment uses its own Time Zones database. Time zone ID format in Java (“Region/City”) differs from NetWare syntax, so there is no direct conformity between NetWare Time Zone and JRE Time Zone ID.
The JRE Time Zone that is set by default is based on the time zone where the program is running. Therefore it might depend on the country chosen during NetWare installation. This is why it is important to keep JRE Time Zone information up-to-date.
You need TZupdater v1.3.40 or a more recent version. It contains the latest information about Russian time zones and corresponds to the Olson Tzdata version tzdata2011h. The TZupdater tool supports JDK/JRE version 1.4.0 and later releases (1.4.0, 1.4.1,1.4.2, 5.0, and 6), and is applicable to NetWare 6.0 (with JRE v1.4.1 or 1.4.2 installed) and 6.5.
- Download TZupdater from the Oracle site. Go to the URL http://www.oracle.com/technetwork/java/javase/downloads/ and select the link “JDK DST Timezone Update Tool”.
- Copy TZupdater ZIP file to a temporary directory on the NetWare server (for example sys:\tmp). Unzip it with the console command:
unzip -j sys:\tmp\tzupdater-1_3_40-2011h.zip -d sys:\tmp
- Update the JRE:
java -jar sys:\tmp\tzupdater.jar -f -bc -v
- Force the JRE to use an exact time zone. It is done by adding the -Duser.timezone parameter to the command line used to start Java application.
java -Duser.timezone="Asia/Vladivostok" ...
Useful timezone values in Russia are as follows:
To check current time and time zone in JRE you can use the Java programming examples available in the Internet. I used the following ones:
- GetSystemTimeZone (http://www.roseindia.net/java/java-get-example/GetSystemTimeZone.zip);
- GetGMTTime (http://www.roseindia.net/java/java-get-example/GetGMTTime.zip);
- DSTTest (http://java.sun.com/javase/timezones/DSTTest.java).
Using these Java programming examples is pretty simple.
- Extract downloaded ZIP files. Copy *.java files to a temporary directory on NetWare server.
- Compile java program:
javac -g sys:/tmp/GetSystemTimeZone.java
- Run java program:
java -cp sys:\tmp GetSystemTimeZone
You might use the -Duser.timezone parameter here as well:
java -Duser.timezone="Asia/Omsk" -cp sys:\tmp GetSystemTimeZone
- Look at the Logger Screen to check the result
What if you missed the last Sunday in October?
If you missed the last Sunday in October, the local time on your servers would be erroneously shifted one hour back. On the other hand, hopeful news for you in November would be the fact that UTC time still remains continuous. This is good for eDirectory health.
Please keep in mind that UTC time is calculated based on the local time and time zone information (zone offset and DST offset):
UTC = local time + time zone offset – daylight savings time offset
Because in November you would have to change all three items in the right-hand side of the equation, there is no way to keep UTC time continous while the NetWare OS is running. As for the latest time zone changes in Russia, if you had changed the Time Zone to the correct configuration, the server local time would retain unchanged but UTC time would jump one hour back. It would lead to the Synthetic Time error.
The safe way to tackle this, is to make changes in offline mode.
- Make changes in AUTOEXEC.NCF as described in the part “Updating Time Zone configuration on NetWare OS” point #2 above.
- Initiate the server warm boot with the console command RESET SERVER
- At the beginning of boot up process start server BIOS Setup utility by pressing a dedicated button (it depends on the hardware model, could be “Del”, “F2″, “F10″ and so on)
- Set hardware clock to the correct local time
- Boot up the server and check current time as described in the part “Updating Time Zone configuration on NetWare OS” point #3 above.