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."
Linux tries to use the hardware clock as UTC by default, but has the option to use a local-time hardware clock for compatibility with Windows. Linux normally would only uses the DST and timezone settings for the displayed time.
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.
It's not as simple as that. Not all 1.4 versions are patched for DST, only 1.4.2_11+. Further, there is a patch level for 1.3.1 that has the DST patches as well. 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
Tell that to my Outlook calendar. In two weeks when I host my telecon involving people from several states around the US, how many do you think are going to call on time, an hour early, or an hour late? I'm not looking forward to repeating myself over and over. Besides, 4k is chump change when you're talking about the time wasted when dozens of meetings get screwed up (mainly due to PEBKAC errors, but still.)
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?".
UTC doesn't solve it. 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
If events are scheduled using UTC, then timezone and dst make no difference.
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 w
$ 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.
[~]:user@debian$ date --date="Mar 25 15:00:00 UTC 2006" Sat Mar 25 09:00:00 CST 2006 [~]:user@debian$ date --date="Mar 25 15:00:00 UTC 2007" Sun Mar 25 10:00:00 CDT 2007
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.:)
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.
Linux apps are not somehow magically immune to breakage from DST patches. The simple fact is that if your computer solution comprises software from multiple vendor / maintainers then you should be extremely concerned about the DST change whether you're using Linux, Unix, OS X or Windows. Not only do you have to patch each system, but somehow verify to your own satisfaction that those patches actually work.
Especially if proper timestamping is a mission critical requirement, such as for real time systems, f
Yes, but UTC systems will still display the correct time. They're 100% accurate, they just have the wrong time zone. They will work perfectly well with and agree with patched systems. This is one reason you can login to a server in Cairo from New York: the systems agree that the time is the same. Windows doesn't much care about time zone changes. You'll be able to log in on March 12th whether you're patched or not. The only problem MS made here is by not using UTC for Exchange calendar entries in the fi
To give you an example of a meeting that spans several timezones; we needed to hold a teleconference with people in the UK, Australia and the US. Within the US, a company with offices in New York and San Francisco faces the same issue; you have people in different timezones, who need to agree on a time.
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:
Adjust meetings such that meetings entered in the timezone that's changing are at the same local time (but a different UTC time).
Adjust meetings such that meetings entered in the timezone that's changing are at the same UTC time (but a different local time).
Alert everyone who's involved with a meeting where one or more participants are in a timezone that's changing to check that the time is still valid.
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.
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 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?
NTP will keep you system clock (as Heaven intends) coordinated with UTC.
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?)
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.
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.
Or, of course, you could have dealt with the root cause of the problem: the biannual insanity of running around changing otherwise perfectly good clocks.
How many of you, after all, have told your State legislatures that this is stupid and it's time to opt out?
How many of you, after all, have told your State legislatures that this is stupid and it's time to opt out?
I like DST. I know how to set what clocks I have that still need to be changed. I enjoy the extra light at the end of the day. I am aware that I could just get up an hour early and try to convince everyone else that I have to deal with to do the same, but DST accomplishes that. Also, I live in a city that spans state lines, so having one state opt out would be a real hassle.
I would much rather lobby my legislature to allow wine to be shipped directly to my door. For crying out loud, I can get ammo delivered (and left on the doorstep) without even a signature, why can't I buy wine directly.
So, for all of those who dislike DST, try this: Just get up an hour later.
I am aware that I could just get up an hour early and try to convince everyone else that I have to deal with to do the same, but DST accomplishes that.
Absolutely. Never mind the fact that if we all shifted our schedules by an hour twice a year, then every single store sign displaying their hours would have to be changed twice a year, bus schedules would all have to be re-printed twice a year, hell ANYTHING with times on it would have to be changed twice a year. With DST we retain the same schedules, but you
That extra hour of daylight after work is seriously awesome.
That extra hour working late, waiting for the temperature to come down to the point where you can get into your car without risking second-degree burns?
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?
What if this like that silly-talking-shrub says is somewhat true?
If by doing this you save 10% of your energy bill, because you don't need to use your lights in the house as much?? If you leave the blinds open, you might also be helping to heat your house somewhat. All that good stuff. I have a big house, and any saving can help.
For everyones griping about how a slight deviation in their routine over a weekend none-the-less.
Unlike asking everyone to drive electric cars, this is relatively simple s
Verifying Timezone Settings in Linux [lsu.edu] lists common distros & needed patches and how-to verify settings. Waaay less wordy than the article linked in the summary.
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.
Can someone please explain to me why it has taken so long to get these patches out? From an OS level, isn't this simply a tzdata patch? (Not sure what the equivalent on Windows is).. This doesn't seem like such a huge issue to me. If the logic of the higher level programs is hard coded, then it's hardly the fault of the OS to deal with that. I've been watching people here at work going crazy as they realize that every router, switch, server, and voice switch in the network needs to be updated by next wee
"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......."
If your systems's zoneinfo files are up to date, you'll get output showing DST changes on March 11 and November 4, eg:
$ zdump -v EST5EDT | grep 2007 EST5EDT Tue Mar 6 13:59:24 2007 UTC = Tue Mar 6 08:59:24 2007 EST isdst=0 EST5EDT Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isdst=0 EST5EDT Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isdst=1 EST5EDT Sun Nov 4 05:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 EDT isdst=1 EST5EDT Sun Nov 4 06:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 EST isdst=0
That same command has worked for me on Solaris, Linux systems, and MacOS X.
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.
Man has been telling time for centuries and it wasn't until the DST mess that we started having issues.
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.
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):
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.
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.
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.
Simple (Score:5, Interesting)
Re: (Score:2)
Beware JVM Problems (Score:5, Informative)
Parent
Re: (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
Re: (Score:3, Informative)
Not sure you'd see it in a home situation though.
Re: (Score:3, Informative)
You can set a Windows box to GMT...
Re: (Score:2)
I mean, I want to have the internal clock / BIOS clock set to GMT, but the task bar clock set to whatever timezone I'm in.
Of course you can always change your clock to show GMT (In fact, that's what I do as I only uses Windows for games at home), but that doesn't count.
Re:Simple (Score:4, Interesting)
Tell that to my Outlook calendar. In two weeks when I host my telecon involving people from several states around the US, how many do you think are going to call on time, an hour early, or an hour late? I'm not looking forward to repeating myself over and over. Besides, 4k is chump change when you're talking about the time wasted when dozens of meetings get screwed up (mainly due to PEBKAC errors, but still.)
Parent
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?".
Parent
Re: (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
Re: (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 w
Re: (Score:3, Insightful)
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.
Re: (Score:2)
[~]:user@debian$ date --date="Mar 25 15:00:00 UTC 2006"
Sat Mar 25 09:00:00 CST 2006
[~]:user@debian$ date --date="Mar 25 15:00:00 UTC 2007"
Sun Mar 25 10:00:00 CDT 2007
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:Looks like I'm screwed then (Score:5, Funny)
Parent
Win vs Lin (Score:5, Informative)
Re:Win vs Lin (Score:5, Funny)
Parent
Re:Win vs Lin (Score:5, Insightful)
Exactly. All the competent Windows admins have already switched to Linux.
Parent
Re: (Score:2, Informative)
Especially if proper timestamping is a mission critical requirement, such as for real time systems, f
Re:Win vs Lin (Score:4, Insightful)
Parent
Re: (Score:3, Interesting)
The only problem MS made here is by not using UTC for Exchange calendar entries in the fi
Re: (Score:3, Insightful)
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.
Parent
My Windoz ME system (Score:2)
--
Real daylight savings: http://mdsolar.blogspot.com/2007/01/slashdot-user
NTP? (Score:4, Interesting)
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?)
Parent
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.
Parent
Re: (Score:3, Insightful)
So I'm afraid your idea is a non starter.
Root Cause (Score:5, Insightful)
How many of you, after all, have told your State legislatures that this is stupid and it's time to opt out?
Re:Root Cause (Score:5, Insightful)
I like DST. I know how to set what clocks I have that still need to be changed. I enjoy the extra light at the end of the day. I am aware that I could just get up an hour early and try to convince everyone else that I have to deal with to do the same, but DST accomplishes that. Also, I live in a city that spans state lines, so having one state opt out would be a real hassle.
I would much rather lobby my legislature to allow wine to be shipped directly to my door. For crying out loud, I can get ammo delivered (and left on the doorstep) without even a signature, why can't I buy wine directly.
So, for all of those who dislike DST, try this: Just get up an hour later.
Parent
Re: (Score:3, Insightful)
Absolutely. Never mind the fact that if we all shifted our schedules by an hour twice a year, then every single store sign displaying their hours would have to be changed twice a year, bus schedules would all have to be re-printed twice a year, hell ANYTHING with times on it would have to be changed twice a year. With DST we retain the same schedules, but you
Twelve is even better (Score:3)
That extra hour working late, waiting for the temperature to come down to the point where you can get into your car without risking second-degree burns?
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 d
Re: (Score:3, Interesting)
Simple (Score:2)
Move to Antarctica.
Better article (Score:3, Informative)
Let the circus begin (Score:2, Insightful)
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.
Shouldn't that be... (Score:2)
Or can we come up with an even more involved name?
Late in the game? (Score:2)
I've been watching people here at work going crazy as they realize that every router, switch, server, and voice switch in the network needs to be updated by next wee
How may we help you? (Score:5, Funny)
"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......."
How to verify whether your system is up to date (Score:4, Informative)
A problem with DST in general (Score:3, Insightful)
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.
Parent
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"
I'm worried... (Score:4, Insightful)
I'm coming four hours early.
Recent? It was two years ago... (Score:5, Insightful)
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
I wonder (Score:3, Insightful)
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.