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."
Set you system to run on UTC. No daylight savings hassles to worry about.
Oh, no! You have walked into the slavering fangs of a lurking grue!
$ 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.
How does this work with NTP? Will the system just stay up-to-date from another system that understands the new rules, or does NTP all work on UTC so that it's not aware of this, or something?
How many of you, after all, have told your State legislatures that this is stupid and it's time to opt out?
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.
the media has been touting this as the next Y2K. Just think, a week from now, we'll be commenting on all the articles documenting the plans falling from the sky, governments folding, stock markets crashing and burning. Toasters and Microwave ovens slaughtering entire familys before they escape to live in cross breed sin near Three mile Island and Chernobyl.
My only regret was that I didn't milk that last consultant fee from a client before my router ran me over and stole my truck.
A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort.
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
"Hello - this is Manny and I will be your corporate level support concierge for this session - how may I help you?"
"Oh, Hi Manny, this is Stuart and I'm at our corporate IT HQ. We need help with the new DST configuration, please."
"Ok, Stuart, I'll be happy to provide whatever help I can, if you will just tell me the name of the corporation you're with, along with the contract ID and your callback number, you can hang up and I'll call you back so we can get things started."
"Ummm...Manny...excuse me, but I've never quite understood why you people always ask for the name of the corporation right off...what's up with that, if I may ask?"
"Well, Stuart, in our effort to provide the best quality service, we need to know upfront which company we are serving so we can insure that our responses fit with such things as non-disclosures, corporate culture, etc. As an example, since this incident deals with DST, if you are with Siemens, we're instructed to use twenty-four hour time, such as the time now being sixteen-forty-two hundred hours. If you are with Hertz Car Rental, the time is four forty-two pm."
"Oh, I see. Well, I'm with Microsoft, Manny, so what does the system say you should tell me?"
"Microsoft - I see. Well, Stuart, the big hand is on the four and the little hand is......."
Actually this isn't a problem with any OS or the computer industry. It is a problem with Daylight Savings Time. Man has been telling time for centuries and it wasn't until the DST mess that we started having issues. This is on the same lines as the US not using the metric system.
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"
It's pretty funny all this fuss about DST changes. Here in Brazil we had to cope with DST changes almost every year for the last 20 years, and by now we pretty much got used to it, on our daily lives and when developing or maintaining computer systems. Every system administration knows that he'll have to update the tz database year, or update the Windows registry accordingly.
I guess that's proof that in adversity, we thrive. Thanks to the screwed up economy we had a few decades ago, we know have one of the most advanced banking systems in the world. Thanks to retarded DST policies, we learned how to adapt from that :)
Close the world, open the NeXT
Funny thing about the 'act' that was passed is it has a clause about congressional review. So at some point, congress could have said "This is stupid" and undone the DST change. Everyone was waiting for the fall session to start, I suspect, to ensure the DST change was going to stick.
g ate/usr/src/lib/libc/port/gen/localtime.c?r1=1138& r2=0
Further, if your running Solaris it's not just a TZ patch. There's libc changes:
http://src.opensolaris.org/source/diff/onnv/onnv-
There's also glibc issues in RHEL 2.1 but they're not quite the same as Solaris.
http://kbase.redhat.com/faq/FAQ_41_9949
Cheers,
Rich
I'm coming four hours early.
It's not wasting time, I'm educating myself.
It was two years ago that this was signed into affect... this shouldn't be the rush that Microsoft, Cisco, and all the rest are making it. Slackers wasted one and a half years doing almost nothing... and now we get this.
That extra hour of hiding in your air-conditioned house waiting for the temperature to come down to the point where cooking dinner won't run up the bill for the whole month?
That extra hour of waiting for it to cool off enough that you can get some chores done without risking heatstroke?
And don't forget:
The one less hour before work at the only time of day when you can actually go outside for more than a brief dash?
The one less hour before work when you can do chores without risking heatstroke?
The one less hour before work when you might even (briefly) enjoy being outside during the early spring and early fall?
Yeah, great idea. Keep people inside with the AC cranked up. That sure saves the country energy.
Lacking <sarcasm> tags,
You're posting to Slashdot about a problem with a date? And you think you're gonna get screwed? I'm not sure if this is redundant or wishful thinking. :)
Yeah, we're here, but we already installed the update without fanfare and are now chuckling at the angst in some of the posts in this article. :)
In fact, my server is still running 10.2 and Patrick has released a patch for that version as well, and probably a few others.
And what happens if someone if one country/state wants to connect to an NTP server in another? If that NTP server only gives its local time then that computer will get the wrong time and if it gives all timezone times then not only will it send FAR more data but you'll STILL have to set the timezone in your machine anyway so it can select the correct one from NTP.
So I'm afraid your idea is a non starter.
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
I wonder why we don't just keep GMT (or whatever your local time zone is in Winter, when midday occurs about 12:00) all year around, but have businesses open from 19:00 to 17:00 in the Winter and 08:00 to 16:00 in the Summer? That way, there is no need for messing about with clocks or anything (except the alarm). After all, the hours of daylight (which increase steadily from Yule until Midsummer) are always split evenly around midday, whether you call it 12:00, 13:00 or even 14:00. But 12:00 is just a nice figure to use when it's midday.
Je fume. Tu fumes. Nous fûmes!
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.