Slashdot Mirror
Linux Systems and the New DST
An anonymous reader writes "The recent changes in the Daylight Saving Time will affect virtually all computer systems in the US one week from now. Microsoft has been busy preparing Windows users for 'Y2DST,' and all the major Linux distributions have also issued patches. How can you be sure your Linux systems are ready, and what can you do to get them ready if they're not? This how-to article at Linux-Watch answers both questions in simple language and with easy-to-follow instructions."
$ date --date="Mar 25 15:00:00 UTC 2006"
$ date --date="Mar 25 15:00:00 UTC 2007"
If the output of both shows the same time (eg. 10:00 EST) then you've got a problem. If they show different times (eg. 10:00 EST and 11:00 EDT) then your system is ok.
Funny how with Linux there isn't any danger of your entire system breaking. I know we spent every day since the Windows patches were relased, testing and make sure the patches don't break anything. So far our Exchange server had to be restored from backup once already b/c all the calendar entries got screwed up.
A certain retarded AC has no idea how an OS that starts with a W works.
You can set a Windows box to GMT...
I don't give a damn for a man that can only spell a word one way.
Mark Twain
However, if you're using an old zoneinfo file for local time, the interpretation of that UTC time is something else again, and NTP won't help you at all.
(Well, assuming you don't live in Arizona or Hawaii. Indiana's timing sucks, doesn't it?)
Lacking <sarcasm> tags,
Verifying Timezone Settings in Linux lists common distros & needed patches and how-to verify settings. Waaay less wordy than the article linked in the summary.
If the govt becomes a lawbreaker, it breeds contempt for law, it invites man to become his own law, it invites anarchy
If you have systems running JVM 1.3 that interact with systems using 1.4 or above, beware, there are issues in how they implemented the fix in 1.3. In Java 1.3, the DST change is applied to ALL years, including prior to 2007, so if you have a remote object on 1.3 give a date to an application running in 1.4 (as a binary object, not just text) then it will cause problems, it will set it to 1 hour off, if you don't use timestamps, the default will be midnight, so one hour off will be the previous day. This has caused a bunch of problems where I work.
For Solaris you can still use zdump, just with a timezone entry instead of /etc/localtime:
zdump -v US/Eastern | grep 2007
From BigAdmin
The jModule
I've seen and heard a lot of people say "I run NTP, I'm immune to this". Sadly, they're just showing that they don't know how NTP works, even on a basic level.
NTP as a protocol tracks the number of seconds elapsed since 1 January, 1900 UTC. It has absolutely zero knowledge of timezones or what they mean. Your NTP daemon of choise just sits there keeping your system clock reasonably accurate with UTC time and it's the relevant libc C time functions that read that UTC time, then read in the set zoneinfo data, and combine the two to give you and your apps local time.
I have some servers running RH 7.3 for which there are no rpm-based updates that I could find (fedoralegacy having closed down). I followed the instructions in the article to update /usr/share/zoneinfo, but that alone doesn't do the trick. The file /etc/localtime on these systems is a static binary, not a link to /usr/share/zoneinfo/America/New_York or whatever's appropriate for your timezone. The fix is simply to delete /etc/localtime and create a symlink with the same name to the correct zone data in /usr/share/zoneinfo.
Skipping all the crap and presuming you have an older distro that doesn't to automatic updates, I'll summarize the steps needed (Do this at your own risk, but it should work on any even remotely standard distro, even very old ones):
/tmp /usr/share/zoneinfo/EST5EDT /etc/localtime
;-)
/etc/localtime | grep 2007
cd
wget --passive-ftp ftp://elsie.nci.nih.gov/pub/tzdata2007c.tar.gz
tar -xzvf tzdata2007c.tar.gz
zic northamerica
ln -sf
If you live outside the civilized world, insert the appropriate time zone in place of EST5EDT.
And finally, verify it with:
zdump -v
Which should say "Mar 11" and "Nov 4"
If it's 4:42, wouldn't the big hand be closer to the 8?
For most of human history, time meant local solar time, or time by the moon and stars. It isn't until the mid 18th C. that the "longitude problem" is solved by the invention of precision marine chronometers. It isn't until the mid 19th C. that the "standard time" demanded by the telegraph, the railroad, trade and industry, intrudes on the lives of ordinary people.
If events are scheduled using UTC, then timezone and dst make no difference.
But if Outlook has "Y2DST" bugs, it stores or assumes that date/time is in local time, so events may be wrong if DST or the timezone of your server changes.
Note that these bugs if they exist could be reproduced otherwise by changing the timezone while programs are running. Events should happen at the same time, independent of timezone. (A real situation would be flying a live system/laptop to a new timezone).
But the bug in Windows is at a low level. Windows, for backward compatibility to DOS, assumes the hardware clock is local time. Any program that depends directly on the local time here, needs more than trivial algorithms to handle timezone and DST algorithms. These algorithms will fail, obviously if DST unexpectedly changes, and are probably in general not really expecting timezone to change. ( These algorithms could be compared with Y99-Y2K algorithms that tried to convert from a two digit year).
And obviously any programs that have such low level DST/Timezone handling code would fail if someone set the not often used RealTimeIsUniversal=1 in Windows.
In general no program should rely on local time, internally. Local time should only be used to convey information to the user. "You appointment is at XXX in your timezone", or "What time in your timezone would you like to schedule your meeting alarm?".
I did my old FreeBSD systems yesterday. The procedure was as follows:
s rc/share/zoneinfo/northamerica?rev=1.31
/usr/src/share/zoneinfo/northamerica
/usr/src/share/zoneinfo do a 'make install' - this compiles the rules into /usr/share/zoneinfo/.
/usr/share/zoneinfo/ to /etc/localtime.
/etc/localtime in chroot trees, e.g. /etc/bind/. If so, copy the new one there too.
/etc/localtime to the rest.
1) Fetch the new rules file. I got it from:
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/
2) Save it as
3) In
4) Run tzsetup - this copies the proper file from
5) Do a 'locate localtime' to see if you have any copies of
If you have multiple identical systems you can do this on one and then copy the new
It's not possible to get a perfect solution to the problem. The best design I've seen stores times in UTC, together with a description of the entry timezone and the offset. Each user has a current local timezone (and it's assumed that users who travel will track these problems for themselves). When a change to DST comes along, the administrator can do some or all of the following:
The system also allows users to override the entry timezone on a per-entry basis. This means that I can enter a meeting in the UK marked as 9am Atlanta time, and be confident that it'll not only appear properly, but that if Atlanta's timezone changes on me, it'll be updated properly.
I appear to have a blog. Odd.
Just a head's up to anyone running Red Hat that their DST patch is incorrect. It's switching to Daylight Saving Time two hours earlier than it's supposed to.
CST6DST Sun Mar 11 05:59:59 2007 UTC = Sat Mar 10 23:59:59 2007 CST
isdst=0 gmtoff=-21600
CST6DST Sun Mar 11 06:00:00 2007 UTC = Sun Mar 11 01:00:00 2007 DST
isdst=1 gmtoff=-18000
CST6DST Sun Nov 4 04:59:59 2007 UTC = Sat Nov 3 23:59:59 2007 DST
isdst=1 gmtoff=-18000
CST6DST Sun Nov 4 05:00:00 2007 UTC = Sat Nov 3 23:00:00 2007 CST
isdst=0 gmtoff=-21600
Clock's are supposed to roll forward an hour at 1:59 A.M. not midnight.
We're having some fun with these patches. We've got about 400 machines to update (with three people) and are running about two dozen different releases of FreeBSD, OpenBSD, Red Hat Linux, Debian Linux, SCO, Solaris and Windows operating systems. And those are just the production servers; I can't wait until we do desktops.