Operating systems optimize

Update Linux and FreeBSD systems for new Daylight Saving Time settings

Daylight Saving Time starts three weeks earlier in 2007, which may cause problems for some companies as they scramble to alter their IT networks so scheduled software and clocks will remain accurate after the change. Linux users will need to ensure that their computers are compliant with local Daylight Saving Time schedules.

This article is also available as a TechRepublic download.

Starting in spring 2007, most of the United States and Canada will observe Daylight Saving Time during the period between the second Sunday in March and the first Sunday in November, thanks to acts of the federal legislature. This means that DST begins three weeks earlier than many of us would have expected: on the eleventh of March, rather than the first of April.

This may lead to problems, for some companies, as they scramble to alter their IT networks so scheduled software and clocks will remain accurate after the change or, worse, as some of them do not think to make any changes at all. Most users of Microsoft Windows, Linux, and other operating systems will need to ensure that their computers are compliant with local Daylight Saving Time schedules.

Thankfully, the common use of comprehensive software archives in free UNIX-like operating systems such as most Linux distributions and FreeBSD ensures that for most users of these operating systems, the change will go unnoticed. As long as you keep the software on your computer updated regularly, the new time zone configurations should already be in place.

For some users, however, things are not so simple. In some cases, users may not find it convenient or even practical to use their operating systems' software management tools to update software from the central archives. These cases include examples where there is no Internet connectivity or where such connectivity is limited so that regular software updates are not feasible, such as having only dial-up Internet access. For these users, the problem becomes slightly less straightforward.

Checking configuration

For those of you in an affected time zone, the first thing you should do is check your time zone configuration to determine whether it is set up to use the new Daylight Saving Time schedule. The following has been tested on FreeBSD 6.1-RELEASE, Debian GNU/Linux Etch, Fedora Core 6, and even legacy Red Hat 9, and worked appropriately in all cases:

  $ zdump -v /etc/localtime | grep 2007

You have nothing to worry about if that command's output looks something like the following for the Mountain time zone:

  /etc/localtime  Sun Mar 11 08:59:59 2007 UTC = Sun Mar 11 02:59:59 2007 MST isdst=0 gmtoff=-25200
  /etc/localtime  Sun Mar 11 09:00:00 2007 UTC = Sun Mar 11 04:00:00 2007 MDT isdst=1 gmtoff=-21600
  /etc/localtime  Sun Nov  4 07:59:59 2007 UTC = Sun Nov  4 02:59:59 2007 MDT isdst=1 gmtoff=-21600
  /etc/localtime  Sun Nov  4 08:00:00 2007 UTC = Sun Nov  4 02:00:00 2007 MST isdst=0 gmtoff=-25200

The key parts of that output are the dates. If you see Sun Mar 11, you don't need to change anything. A result of Sun Apr 1, on the other hand, means you need to update your software to match the new schedule.

Updating from Software Archives

A simple software update from the central repositories using your distribution's or operating system's software management tools should do the trick if that is an option. Such tools include, for instance:

  • APT or Synaptic for Debian GNU/Linux, or Debian-based Linux distributions such as Ubuntu and Knoppix
  • urpmi for Mandriva Linux
  • YAST2 for Novell SUSE Linux
  • YUM for Fedora Core or Yellow Dog Linux

Additionally, FreeBSD, Slackware Linux, and other free UNIX-like operating systems have their own tools for the same tasks. They are almost invariably easy to use, and the wide availability of open source code ensures that the likelihood of being able to solve the problem using nothing more than standard software management tools is very high.

Even if you do not have direct access to the archives for some reason related to bandwidth or security concerns, you can download the necessary package upgrades from your operating system vendor's or project community's main Website. The methods will vary from operating system to operating system, but they should all provide tools for installing the packages without direct access to the archives. See your operating system documentation for details. Below is a list of links to the relevant software updates for common operating systems:

Manually updating

In cases where the port or package you need to update your time zone configuration is not available, you should be able to change the configuration yourself almost as easily. Before downloading the tzdata file according to the following instructions with the wget command, double-check to make sure you have the right filename by visiting ftp://elsie.nci.nih.gov/pub/. You should do your work in a temporary directory when performing these actions so you will not accidentally overwrite important files. The following set of commands works on most systems, assuming that the appropriate tzdata file for download is tzdata2007b.tar.gz:

  # wget 'ftp://elsie.nci.nih.gov/pub/tzdata2007b.tar.gz'
  # tar -xzvf tzdata2007b.tar.gz
  # zic -d zoneinfo northamerica
  # cd zoneinfo
  # cp -r * /usr/share/zoneinfo/

At this point, you should check to ensure the correct data is in place. The following includes two checks. One is for a time zone file, and the other is for a city file, where you should choose the city in the indicated directory that is nearest your location.

  # zdump -v /usr/share/zoneinfo/CST6CDT | grep 2007
  # zdump -v /usr/share/zoneinfo/America/Chicago | grep 2007

The output of both these commands should display the newly updated Daylight Saving Time dates. You may have to use the ln -s command, possibly with the -f option as well, as indicated in the following example. This will point your /etc/localtime file at the correct data for your time zone. The output of the zdump command, as presented earlier in this article, will show whether it matches expectations for the new Daylight Saving Time schedule. For example, if your time zone is Central (US), you might use this command string:

  # ln -fs /usr/share/zoneinfo/CST6CDT /etc/localtime

The ln command creates a "link" between a target file and a local filename, so that both point at the same data. The -s option makes it a "symlink" or "softlink", so that one reference is the "real" file and the other is just a "shortcut" to it. Making changes by writing to one affects the other for reading purposes; see the ln manpage for more details. The CST6CDT listed here relates to the Central Standard Time and Central Daylight Time settings for time zones, with a Standard Time offset of -6 hours from Greenwhich Mean Time.

All you really need to know, if that doesn't make sense to you, is which set of letters stands for the name of your time zone. The following simple table may help, though it is not comprehensive:

Time Zone Abbreviation
Eastern EST5EDT
Central CST6CDT
Mountain MST7MDT
Pacific PST8PDT

This should cover the most common North American time zones.

Once this is done, you can delete the contents of your temporary directory where you initially downloaded the tzdata file, and you shouldn't have any further problems with automatic Daylight Saving Time adjustments on your system.

At least, until the next time Congress passes a law that sends your IT department into a panic.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

11 comments
admin
admin

Thank you for the guide. It was only way for upgrade TZ on my Slack 8.0 boxes!

neilrahc
neilrahc

Very helpful - I easily updated RH ES3 and FC3

jmgarvin
jmgarvin

Great article. As always, very helpful and easy to follow.

techrepublic
techrepublic

it should be ln -sf /usr/share/zoneinfo/CST6CDT /etc/localtime as written, it overrides the data you just installed with the old file that was wrong to begin with. the zdump line validates the change: zdump -v /usr/share/zoneinfo/CST6CDT | grep 2007

techrepublic
techrepublic

The tz filename changed since this article was tested - it is now on version "c" - change the wget line as shown: # wget 'ftp://elsie.nci.nih.gov/pub/tzdata2007c.tar.gz' # tar -xzvf tzdata2007c.tar.gz # zic -d zoneinfo northamerica # cd zoneinfo (You may have to unalias cp here: # unalias cp) # cp -r * /usr/share/zoneinfo/ I found a bunch of timezome files in /tmp, above the tarball directory - you might want to clean them up too. They are owned by UID 8800.

apotheon
apotheon

Thanks for the positive feedback. I'm glad it proved helpful.

apotheon
apotheon

I'm glad it worked out for you.

apotheon
apotheon

. . . thank you for the compliment.

stress junkie
stress junkie

I checked the /etc/localtime file to see what it was. The file command said that it was timezone data, not a link, so I decided to see if it would work without changing it. I rebooted and my desktop clock is now showing the correct time. So, before you change that file try rebooting to see if the existing file is okay. The other correction about the wrong file name "elsie.nci.nih.gov/pub/tzdata2007b.tar.gz" still needs to change to tzdata2007c.tar.gz of course. Otherwise the instructions were very helpful. I gave the article a 5 rating. :) I almost never do that.

apotheon
apotheon

You're right. I'll ask the editor to change that.

apotheon
apotheon

The file need not necessarily be a link for everything to work. That's why I provided the zdump command example to check on your system timezone DST configuration. The reason the filename appears to be out of date is that the filename changed several times over the last few months. I foresaw the possibility that it would change again (as it did), which is why I suggested that you check the filename before downloading the tzdata file. Thanks for the positive review of the article. I appreciate feedback of all (reasonable) kinds.