| UPDATED: Switching your Linux systems to the new DST |
Mar. 09, 2007
"Spring forward; Fall back," That's the way the saying goes. Some years I get it backwards, but I eventually catch on. I've never had to worry about my PCs getting it wrong before, though. Now, with the recent changes in the Daylight Savings Time (DST) rules, I do.
Fortunately, there are ways to make sure that both my Linux computers and I get the new rules right.
Until now, most of us in the U.S. would set our clocks forward an hour in April and back an hour in October. However, in 2005, Congress passed the Energy Policy Act, which amended the Uniform Time Act of 1966. This turned our old, reliable Daylight Savings Time completely inside-out. The change goes into effect this year.
From now on, instead of DST starting on the first Sunday in April, it starts on the second Sunday of March. (This year, that's March 11.) Come Fall, Daylight Savings will end on the first Sunday in November -- November 4, this year -- instead of the last Sunday of October.
That means one big mess for many pre-2005 programs and operating systems, which have the old April/October DST rules hardwired into them.
Now, unlike Windows, Linux and the rest of the Unix operating system family don't have Daylight Savings Time innately. Instead, they use an entirely different way of telling time.
Most Linux systems have two clocks. The hardware clock, a.k.a. the "CMOS clock," is present in most x86-based systems. The CMOS, a battery-backed time clock located on the motherboard, runs 24/7. The system clock, on the other hand, starts when you boot up your system. This is the clock used by most internal Linux programs and Linux applications.
By default, the system clock takes its cue from the CMOS. A far better way to set up the system clock, if you have an Internet connection (and who doesn't?), is to use a program like ntpd. This program uses the NTP (network time protocol) to obtain the correct time from an NTS (network time server).
Some older Linux and Unix systems required you to use a program called ntpdate to actually set the time manually. Now, that functionality is included in the ntpd package.
The system clock, no matter how you update it, doesn't keep time the way most of us do. For Linux, the universe began at midnight UTC (a.k.a. Coordinated Universal Time), or 12:00 a.m. on Jan. 1, 1970. The system clock tells time by counting the number of seconds since the Linux "universe" began. This method of telling time is referred to as the Unix Epoch.
(As an aside, since most computers store the Epoch's number of seconds as a 32-bit signed integer, the "End of Time" will come at 03:14:07 UTC on Tuesday, Jan. 19, 2038. That, however, is a problem for another day.)
Notice something missing? In all this talk of timekeeping, there's no mention of DST -- or of time zones, for that matter. That's because Linux doesn't track those with its time programs. Instead, Linux stores its time zone and DST information in the specific file, /usr/share/zoneinfo. Older Linux systems may store the information in the file, /usr/lib/zoneinfo, instead. The local time zone and DST are both usually determined by a symbolic link to /etc/localtime.
To make sure your Linux system knows when DST is, this year and ever on, you need to update your zoneinfo file, or replace it with one that contains the new rules.
If you've been keeping your system updated, most modern Linuxes will have automatically updated your computer with the correct DST information. If you haven't updated your computer for a while with the latest patches, do it now. That may be all you need to do to be ready for the new DST.
Some (but not all) Linux and Unix distributions give instructions on how to use their update tools to set your system up with the new DST. The ones we're aware of at this time are AIX, Debian Testing, Debian Unstable, FreeBSD, Novell SUSE Linux Enterprise, Red Hat Linux, Mac OS, and Solaris.
Once you've done that, it's time to check to see if you have the right DST settings. How do you make sure? Unfortunately, you can't just look at your zoneinfo files; they're not human-readable.
Instead, you need to use the zdump command from a shell interface. Zdump prints the current time in each zonename named on the command line. For our purposes, you'll need to run the following command:zdump -v /etc/localtime | grep 2007
If you don't get any result from the zdump command, your system may need you to specify your time zone information.
For example,$ zdump -v /etc/localtime EST5EDT | grep 2007
is what you would use for the U.S. Eastern time zone. If you're in the Central time zone, use CST6CDT; in the Mountain time zone use MST7MDT; and in the Pacific time zone, use PST8PDT.
If your system is set up properly, it will return a display that starts with two lines containing "Sun Mar 11". If, instead, you see a pair of lines with "Sun Apr 1" within them, you'll need to do a manual update.
This will take a little time at your shell interface, but it's not difficult.
First, you need to see exactly how much work you'll need to do. For example, older Linux systems, such as Red Hat 9 and earlier use versions of the glibc library whih are older than 2.3.2-64 (circa July 28 2003). In these older glibc files, the zoneinfo is actually integrated into the library. If that's your situation, you'll also need to upgrade glibc to 2.3.2-65 or later. You may also need to upgrade other associated C files to glibc-common-2.2.4-32.23; glibc-devel-2.2.4-32.23; glibc-profile-2.2.4-32.23 and nscd-2.2.4-32.23.
What version do you have? You can find out by running:If you have an older version, you'll need to update it. As you might guess, the details vary on how to do this depending upon your distribution. The best thing to do is to see what your Linux provider has to say about fixing up your specific distribution. Another way is to use the code file, tzcode2007c.tar.gz. First though, let's get the timezone data files.
So, use your Web browser to check for the most up-to-date time zone and DST information files at the site:ftp://elsie.nci.nih.gov/pub/
When I checked on it, on March 5, the most current data file was tzdata2007c.tar.gz.
Next, if you don't have a directory you already use for temporary files and downloads, set one up. A good name for such a directory in this case might be tzdata. You can make this directory, and then move to it with the following commands:$ mkdir tzdata
$ cd tzdata
Now, download it to your system with at ftp utility. If nothing else, you almost certainly have a copy of wget. Run:$ wget ftp://elsie.nci.nih.gov/pub/tzdata2007c.tar.gz
Once you have the file in hand, decompress it with an archive utility such as tar:$ tar -xzvf tzdata2007c.tar.gz
Now that you have the chronological information you need, it's time to put it in the proper format. You can either switch to the root user, or use the sudo command, to run the following:# zic -d zoneinfo northamerica
# cd zoneinfo
# cp -r * /usr/share/zoneinfo/
Zic will transform the data into the form Linux needs; and the other commands will copy the new information to the proper directory. If you're using an older version of Linux, you may need to place the file in that directory like so:# cp -r * /usr/lib/zoneinfo/
Some systems do not automatically link from /etc/localtime to either /usr/share/zoneinfo on newer Linuxes or /usr/lib/zoneinfo on older versions of Linux. If you're still not geting the right date, run the following command either as root or by using sudo:ln -fs /usr/share/zoneinfo/CST6CDT /etc/localtime
Insert the appropriate file directory name with your local time zone into your command. This creates the symbolic link to the correct DST setting.
Now, if you have didn't need to update your glibc files, you're good to go. If you're still stuck with older glibc, you need to download tzcode2007c.tar.gz and place it in a temporary directory. I sugest using one called tzdir. Once it's there, decompress it with a command like...$ tar -xzvf tzdata2007c.tar.gz
Within this new directory tree, you'll now find a "Makefile." Read it and make any changes needed to make things right for your system, and then run the commands it gives you. Be certain, of course, to use the installation directory that's right for your system.
All done? Now, let's check to make sure we're set up properly with the new DST by going back and using our zdump routine again:zdump -v /etc/localtime | grep 2007
An amusing way to check is to visit the University of Minnesota's DST time check site. This detects if your system is set up correctly by using JavaScript. This will work with any system that has a JavaScript-enabled Web browser. The site will display a big end-user-friendly green, yellow, or red dot depending on your PC's DST settings.
All set? Great! I told you it wasn't too hard.
The final touch is to make sure all your daemon services know about the DST change. Many important background applications, like sendmail, postfix, MySQL, and BIND named, only load /etc/localtime -- that is, they only check the date and time -- when they're starting up. Rather than track such applications down, the best thing to do is to simply reboot the system. That way, all the services will start fresh, with the correct DST time information safely locked into your CMOS clock.
At this point, your PC should be fine until either Congress changes the DST rules again, or we reach the Epoch. Here's hoping that it will be the Epoch, and not another government mandated time change.
Hey, look on the bright side: at least it's not Y2K and you're not trying to set DST up properly in Windows!
[And a tip of the hat to bill, jimbudler, mikeraz, willi290, keys and others whose suggestions and questions helped improved this revised article. Any mistakes remaining are all mine.]
-- Steven J. Vaughan-Nichols; originally published on March 5
Do you have comments on this story?
Talkback here
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
news feed