Unsupported machines and Options for the Daylight Savings Time changesThe following are 4 options for dealing with the Daylight Savings Time change issue on older, unsupported machines:
- Do nothing. This may be viable if the machine is lightly used or unused and does not run any services that are critically dependent on correct local time. On April 1st, the old DST start date, the local time will again be correct. Note that kerberos authentication will continue to work as it does not rely on local time, rather it relies on the system clock which will be correct.
- Change the timezone for the 3 week period between 3/11/07 and 4/1/07. Local time will be correct but the timezone setting will be off by one hour. If you choose this workaround you must remember to set the timezone back to the correct timezone on April 1, 2007.
Note: For instructions on how to manually change the time zone see the section Manually choosing the time zone on unsupported machines below
- Install the Daylight Savings Time updates for your system. Help regarding how to find and apply these updates can be found below.
- Ask to have your machine supported by SCS Facilities and have the OS upgraded to include the necessary Daylight Savings Time updates. This option may not be available to all machines as some may not be upgradeable due to hardware limitations. Please note that an existing backlog of OS upgrade work is already in place. New OS upgrade requests will be handled in turn and there is no guarantee that such requests will be honored prior to March 11, 2007.
Manually choosing the time zone on unsupported machines
If a system administrator chooses to change the time zone on an unsupported machine the following information will help to assure the change has been done correctly.
The following timezones that are appropriate:
|EST5EDT||Which will work as expected on patched machines Unpatched ones will not do it correctly Mar 11 - Apr 4 etc|
|GMT+5||Which is five hours off of GMT, just like we are now.|
|GMT+4||Which is four hours off of GMT, just like EDT.|
Setting an old machine to use the timezone GMT+4 will satisfy most unpatched machines, until April 1, 2007 which is when the timezone should be reset to the default value so that local time remains correct.
This document describes some options for handling the change in timezone information for Solaris and Linux machines.
|Operating System||Support Level|
If your machine is under support, facilities will apply patches and updates well before the end of february. These patches are currently being alpha and beta tested before being pushed out to all supported Solaris and Linux machines.
If your machine is not under support, facilities staff members may not be available to update, fix, or workaround the problem on your machine. Facilities staff members may or may not be available to supply additional advice on how you might be able to work around problems on unsupported machines.
If you have an unsupported machine, it is very possible that the information below will be enough to help you work around this problem.
If your machine is under support, facilities will supply patches. If your machine is not under support, you may find information about vendor patches from the list below.
The timezone source files will be in tzdata*.tar.gz. You can expand this file with gzcat and tar to get the timezone source files. The timezone source files will be named
In addition to the above listed timezone files you will see 4 other files that are used in the update process which is described below. These are:
|Timezone Source File Location||/usr/share/zoneinfo/src|
|Compiled Zone Files||/usr/share/zoneinfo||/usr/share/lib/zoneinfo|
|Default Timezone||/etc/localtime timezone file||/etc/default/init variable setting|
If your machine
- is not receiving facilities support
- and has no vendor patches available
- Retrieve the timezone files from the above location
- Become root on the machine in question
- Unzip and untar the files into a temporary directory
- Save a copy of the currently installed timezone files in case something goes wrong
- Cd to the temporary directory where you placed the source files
- Compile the new timezone source files with the timezone compiler /usr/sbin/zic
- The command line should be as follows: /usr/sbin/zic -L ./leapseconds -y ./yearistype.sh (FILENAME)
- Run the above command on all of the source files, making sure that you compile the file 'backward' last.
- Copy the new zone.tab and iso3166.tab files to the /usr/share/zoneinfo directory
- Reboot your machine
- Confirm that the new timezone files work as expected with the command
/usr/sbin/zdump -v -c 2008 US/Easternwhich should end with the lines
US/Eastern Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isdst=0 US/Eastern Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isdst=1 US/Eastern Sun Nov 4 05:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 EDT isdst=1 US/Eastern Sun Nov 4 06:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 EST isdst=0 US/Eastern Tue Jan 19 03:14:07 2038 UTC = Mon Jan 18 22:14:07 2038 EST isdst=0 US/Eastern Mon Jan 18 03:14:07 2038 UTC = Sun Jan 17 22:14:07 2038 EST isdst=0
- On linux issue the command
cp /usr/share/zoneinfo/US/Eastern /etc/localtime
The syntax of timezone source files have changed over time. Old versions of the timezone compiler, such as those on some sun4_413 machines are not able to compile the latest timezone source files.
If you do not compile the file named backward last, then the newly created timezone files may contain errors.
The actual compiled binary format is generally platform independent. There are however two versions of the compiled timezone files. It may be possible to compile new timezone files on another more up to date platform, and move these to your unsupported machine. You may need an update to libc to be able to understand the newer compiled binary format. Updating libc may cause many other problems, and should probably be avoided except for the most knowledgable of users.