Linux Systems and the New DST 304
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."
A very simple *nix test (Score:5, Informative)
$ 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.
Win vs Lin (Score:5, Informative)
Re:Simple (Score:3, Informative)
You can set a Windows box to GMT...
Re:NTP? (Score:5, Informative)
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?)
Better article (Score:3, Informative)
Beware JVM Problems (Score:5, Informative)
Re:Win vs Lin (Score:2, Informative)
Especially if proper timestamping is a mission critical requirement, such as for real time systems, financial trading etc. In fact it's even worse for something like trading since you may be talking about literally hundreds, or thousands of distinct subsystems passing timestamps around between each other.
Solaris Test (was Re:A very simple *nix test) (Score:3, Informative)
For Solaris you can still use zdump, just with a timezone entry instead of /etc/localtime:
zdump -v US/Eastern | grep 2007
From BigAdmin [sun.com]
Re:NTP? (Score:5, Informative)
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.
How to verify whether your system is up to date (Score:4, Informative)
Setting DST on older RedHat systems (Score:3, Informative)
The short answer... (Score:4, Informative)
cd
wget --passive-ftp ftp://elsie.nci.nih.gov/pub/tzdata2007c.tar.gz [nih.gov]
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"
Re:How may we help you? (Score:1, Informative)
If it's 4:42, wouldn't the big hand be closer to the 8?
Re:Beware JVM Problems (Score:3, Informative)
Not sure you'd see it in a home situation though.
Re:A problem with DST in general (Score:4, Informative)
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.
Re:Beware JVM Problems (Score:3, Informative)
These are the java versions that natively include fixes for DST in 2007.
1.3.1_18+
1.4.2_11+
1.5.0_06+
So this means all 1.4.0 and 1.4.1 versions will not recognize DST unless you update them. Most vendors provided an update tool (tzupdater/jtzu) that can patch a variety of java versions. There is a table of available options for all vendors at: www.javasanity.org
Windows-only "Y2DST" bugs (Score:4, Informative)
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?".
FreeBSD howto (Score:3, Informative)
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
Multiple timezone meetings (Score:4, Informative)
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.
Re:Win vs Lin (Score:1, Informative)
This means that Linux systems only need a rules update that silently slips into the already existing system that applications were always supposed to use, while in Windows there is functionality change and you could run into problems with applications that do not expect that different rules are present for different years.
So in Windows, you patch your system and have to re-test everything, while in Linux you just load a TZ rule and everything keeps working.
Re:Solaris Test (was Re:A very simple *nix test) (Score:2, Informative)
zdump -v
Re:Windows-only "Y2DST" bugs (Score:3, Informative)
I have a recurring meeting. It is at 11 AM Pacific Time every Tuesday, all year round.
Do I just set it up for 1900 UTC then? No, because when DST takes over, it will be off by one hour. Instead, I set it to 11 AM local time. MS Exchange performs the adjustment and schedules this meeting (and the conference room) for 1900 UTC for the winter months, shifting it to 1800 UTC when the software thinks DST takes effect. It doesn't calculate the times on the fly; it sets up the recurrences when the original scheduling is done. If the meeting was scheduled before Exchange is updated with the new DST, then, for each occurrence between March 11 and April 1, the meeting appears in my Outlook calendar *one hour later than it should*. This is because the updated software knows that 1900 UTC (the scheduled time) is actually noon local time.
What's more, the conference room is now available between 11 AM and noon on Tuesdays, for someone else to schedule a meeting. When IT corrects my meeting schedule for the time change (which they will, as they have advised everyone in the company not to try to do this manually), there's gonna be trouble...
Re:A very simple *nix test (Score:2, Informative)
FYI, Red Hat's Patch is Incorrect! (Score:3, Informative)
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.
Re:Windows-only "Y2DST" bugs (Score:3, Informative)
Given that events (such as periodic meetings) are normally scheduled in local time, that's bogus.
In fact, having the calendaring tool store them in UTC breaks things even more. It means that the tool will convert them to UTC to store them and alarm them, then back to local time to display them. So when DST starts (even if at the EXPECTED time) a periodic meeting moves by an hour.
DST is an unmitigated disaster for programmers who write scheduling software (as I once did for a client). Changing it compounds the problem.