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.
I'm so glad Micro$oft in on top of this. Oh, wait....s -selling-solar.html
--
Real daylight savings: http://mdsolar.blogspot.com/2007/01/slashdot-user
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,
How can you be sure your Linux systems are ready, and what can you do to get them ready if they're not?
Move to Antarctica.
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.
Shouldn't that be the Y2K7DST Bug?
Or can we come up with an even more involved name?
Hopefully I didn't put any [] around my words.
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 week. And the patches for most of these devices *JUST* came out last week! That's hardly time to test! I guess we blindly jump into the fray and hope that the vendor got it right the first time, eh?
*sigh* This was known about a while ago. August 8, 2005 is when the bill was passed. That's a year and a half ago! Long enough that patches should have been out for months now. Apparently we learned nothing from Y2K
*sigh*
XenoPhage
Technological Musings
"Spring forward, Fall back"... you could just as easily say "Spring back, Fall forward" and get yourself totally confused. The mnemonic is plain daft... it should be something that is memorable and doesn't make sense the other way round...
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
Australia went though this last year and as far as I know it went smoothly http://www.sbsusers.org/melbourne/alerts7.htm
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
lets see now...
emerge -u world
yep that should do it
and relax
"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.
$ date --date="Mar 25 15:00:00 UTC 2006" ... ...
date: illegal option -- -
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]]
[-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format]
$ date --date="Mar 25 15:00:00 UTC 2007"
date: illegal option -- -
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]]
[-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format]
There. That should do it.
To see if you're all set, do this:
$ zdump -v America/New_York | grep 2007
America/New_York Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isdst=0 gmtoff=-18000
America/New_York Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isdst=1 gmtoff=-14400
America/New_York Sun Nov 4 05:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 EDT isdst=1 gmtoff=-14400
America/New_York Sun Nov 4 06:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 EST isdst=0 gmtoff=-18000
Substitute your timezone name as appropriate. Look for March 11 and November 4 in the output.
Tired of FB/Google censorship? Visit UNCENSORED!
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.
Never made sense.
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"
The theory behind the new DST is, in fact, intelligent and a positive sign in this otherwise bleak administration.
As for the affect on the IT industry, here where I work as a developer at a large international Fortune 500 company (think: German) it was a simple three step fix that retrofitted all Outlook appointments (or any other applicable piece of software) with the new timing, and patched the computer for the future. The process was easy (even the sales reps figured it out) and the energy payout in the long run (years and years of saving daylight) more than warrant the *slight* hassle.
art is science made clear. -cocteau
NTP does not keep track of time zones, though it would be useful if it did. Having all this time zone information stored on every computer going out of date is pretty dumb. It would be more intelligent to have only the name of the current time zone stored on each computer and all the time zone info stored on a central NIST time server. Then one person maintaining that database would be all the world would need.
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
This change is covered in the glibc-zoneinfo-2.3.6-noarch-7_slack11.0.tgz package, which you can fetch from most Slackware mirrors.
Just thought I'd drop that tidbit of information if there is another Slackware user around here...
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
$ date --date="Mar 25 15:00:00 UTC 2007"
date: illegal option -- -
date: illegal option -- d
date: invalid argument -- te=Mar 25 15:00:00 UTC 2007
usage: date [-u] mmddHHMM[[cc]yy][.SS]
date [-u] [+format]
date -a [-]sss[.fff]
The masses are the crack whores of religion.
We've run into this situation with three of our vendors (HP, Novell and Redhat) where they released patches for DST a while ago (last fall and before), but didn't include the Canadian timezone fixes. Novell has finally released a patch that updates Canadian timezones, and we've got it going on a Redhat box as well, but I heard our HP-UX people are still waiting.
So, if you're Canadian, or have boxes in Canadia, make sure the patch you applied will handle the Canadian timezone rules.
"zdump -v Canada/Eastern | grep 2007" and "zic -l Canada/Eastern" is now forever stuck in my brain from all the testing.
Todd.
We emerge from our mother's womb an unformatted diskette; our culture formats us. - Douglas Coupland
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.
If you're writing a scheduling system, you want everything in UTC. Cause it's independent of locale.
For display purposes, you display a time that's appropriate to the user's locale. If you're concerned about historical
data, you have your display be intelligent enough to know that the DST switch happened in 2007.
WTF was he thinking? This has been a big cluster and has sucked IT resources for the past month.
date -d "Mar 25 15:00:00 UTC 2006"
date -d "Mar 25 15:00:00 UTC 2007"
Paste it to a gnome terminal.
The 60's and 70's education prepared america to cut over to metric. Carter signed the bill in 1982, we were to move America over to it. Then reagan said it would cause too many issues. Gads, that guy was a PISS POOR leader who has caused this country trillions of dollars. I thank god that in another 50 years, historians will be able to look over his crap and will almost certainly decide that he was one of the worse pres. that America had. I only wish that the republicans would get over their demigod status of the man.
$packagemanager $updaterepository && $packagemanager $installupdates
Or a real-world example for gentoo, which takes approx. 15 minutes:
emerge --sync && emerge -u tzcode tzdata
For those of you who do not wish to click your self to death, Intelliadmin.com has a free graphical tool ( up to 3 workstations at a time, 4+ more will cost you. )
I do not work for, own or otherwise benefit from mentioning this product. I just used it and was happy with it.
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,
Search for RealTimeIsUniversal.
http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html
Though, the registry setting is still not officially supported.
They better not have any F-22 Raptor flying until those patches have been rolled out...
Due to the widespread use of Java with enterprise applications, there is a huge issue with Java and DST as well. This article provides good info on how you can fix DST for Java as well. Pretty much every version of Java installed before December of 06 is vulnerable, as the whole java community seems to have been behind on fixing this problem.
d ont-panic-it-can-be-fixed
The following link provides good information for patching Java from the 4 major java providers.
http://www.javasanity.org/article/3/dst-and-java-
Just program clocks to adjust the time so that the sun rises at the exact same time every morning.
Thank You Debian and Ubuntu mybox:~$ date --date="Mar 25 15:00:00 UTC 2006" Sat Mar 25 07:00:00 PST 2006 mybox:~$ date --date="Mar 25 15:00:00 UTC 2007" Sun Mar 25 08:00:00 PDT 2007
I say things which affects my Karma negatively. (and I don't care) For instance; All religion is false.
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?".
Can someone explain why a glibc change is needed ?
Come on people, this really is a simple thing to patch your system to take care of this. Baring that, if you are to lazy to do so just set up a couple of cron jobs to take care of the problem. One to set the correct time on March 11, and one to correct the problem again on April 1st, I think. You'll need two more to correct the time again when we fall back in the fall sometimes.
Best fucking way to deal with this issue would be just to get rid of daylight savings time all together.
I read at +2. If your post doesn't reach that level I will not see or respond to it.
> Don't tell me you're timestamping with local time? Always use UTC and convert to local time on the fly, it avoids all these problems.
Naive, ignorant, or purposefuly misleading...
If you store all time in UTC and convert to local time on the fly, YOU STILL HAVE A PROBLEM. You have a problem because the timezone definitions changed. Someone wanted a meeting at 9am March 25th EST, and scheduled it before you put the new timezone files in place. Your system would translate that to UTC. Timezone files change, and now there meeting is displayed as 8am March 25th EST.
Converting everything to UTC on the backend is good, but if the timezone definitions change, anything marked with a future date, that was marked prior to the updated files being installed, will be broken, regardless of system.
Storing dates in localtime would have actually been better in this case, because 9am is just 9am. Your totally screwed during the 2 days a year that DST changes occur (because one hour happens twice, or one hour never happens), but 9am is always 9am.
Humm, not having such luck here. On Debian Stable (aka "Sarge") I'm still getting the old DST settings even with the allegedly up-to-date versions of libc6.
Running an "apt-get update", followed by "apt-get install libc6", yields an "already the installed version" message, and "dpkg -l libc6" says that I have 2.3.5-13 installed. But the date and zdump commands still give the old DST settings.
And this is with all the official Sarge repos, including stable and stable/updates on mirrors.kernel.org and security.debian.org.
Did they not push the timezone update out to Debian Stable, or what?
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
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
DST definitions vary by country and can be changed by government action.
Seems like they ought to take up some of the slack then - NIST could host timezone files on a server that OS and application vendors could code against - clients would do a basic query for the most recent version, once a month or so, and an XML schema would define the timezones and when they are in effect, and... hmmm, can't think of any more 'and's.
There we go - Congress can fight Democrat vs. Republican on changing the date by one day each way each year (thereby minimizing the time they have to do real damage) and NIST can update the timezone files. If the analysts are to be believed each time there's a change we save $4.7B.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
The Redhat/Fedora tzinfo, since May or June 2006.
Solaris patches, since about March 2006.
Don't know about others.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
we've being doing this for ages in Brazil. You're such whiners!
and charging a lot for it too! I heard it was somewhere between $500-$2000 for a patch depending how old your M$-software is (I'm talking WinNT3&4, and yes I know big credit card systems that are still running these). Yeah, all Unix servers just updated zoneinfo, now you see what you get for being locked into a system you can't change yourself.
By the way: good luck with stuff like SharePoint, if you didn't configure your timezones for each site, it automatically references PST (yes, Pacific), no matter what the rest of your computer configuration says.
And good Windows admins or not, one of the companies I work for has Microsoft themselves updating their Exchange since it already failed twice, screwing up their times and they haven't been successful so far
Custom electronics and digital signage for your business: www.evcircuits.com
I use Fedora Core 3, 4, 5 and 6 at my office. I found that yum updated the files in /usr/share/zoneinfo, but did nothing to /etc/localtime (the zone data that the system actually uses). Actually Core 3 added file /etc/localtime.rpm which was fine if I was located in the US Eastern time zone (I'm not). The manual update was easy, however. To check the current settings:
/etc/localtime | grep 2007
/usr/share/zoneinfo. I am in the US Pacific time zone so I verified that my zone file had been updated by:
/usr/share/zoneinfo/US/Pacific | grep 2007
/etc:
/usr/share/zoneinfo/US/Pacific /etc/localtime
zdump -v
If the DST start date shown is not March 11 then check the file in
zdump -v
Then I activated the updated file by copying it into
cp
Can't figure why they were an hour late for your exit interview...On March 12th.
There's no tzdata available for stable; I think that's a testing and unstable creation.
After some poking around, I realized that my version of libc6 is somehow newer than what's available in stable, but older than unstable and testing, and I have no idea how it got there. This makes me think that it's probably something that's depended on by other things, meaning that it's probably better left alone.
Rather than poke at anything, I think I may just switch it over to UTC and forget about this timezone business. Rewriting some crontabs seems vastly easier than the Bad Things that might happen if I either upgrade libc6 to what's included in testing or unstable, or force a downgrade to what's packaged in stable.
It's a backup server; it shouldn't care what the local time is, anyway. If I'd been thinking when I set it up, I should have just kept it set to Zulu time and wrote my crontabs accordingly.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Just change the damm time people, takes about ten seconds, and then get a life.
The only ones that might have a ligitimate complaint would be those administering more than fifty machines (and those people usually have some kind of remote access with scripting capability).
As I live in Arizona, where we don't do Daylight Savings Time, the solution is easy. Ignore it, it'll still be the same time next week as it is today. For everywhere else, the conversion routines will be sticky, giving incorrect answers for a lot of before/after conversions, but it's only acocuntants that'll mess up. So, hope you enjoy the conversion.
Everybody knows 3 people with my name.
What marketing moron came up with that clueless catch phrase?
Nothing to see here. Move along.
Ooh! Ahh! Help! The world is going to end!
Get over it.
In Australia, DST was extended for a month last year for the Commonwealth Games. Microsoft issued an update for Windows, and NOTHING BAD HAPPENED.
But, this all happened outside of the United States, so it doesn't really matter now, does it?
...then shouldn't the whole continent shift their schedules 1 hour ahead and keep them there?
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.
Well then we should have that hour all year 'round then. DST is totally perverted up here in Canada--we "fall back" in the fall and so the sun sets earlier...just in time so that the short days of winter are even shorter! DST is totally backwards..if anything we should "fall ahead" and "spring back".
I HATE the extra hour of daylight in the summer...where I live that means I have to close all the blinds in my house to go to sleep because it stays light outside until after 10 PM! I HATE early evenings in the winter--it means that by the time I can leave work it's been dark for an hour already!
Also, I live in a city that spans state lines, so having one state opt out would be a real hassle.
No it wouldn't. The city of Lloydminster, Canada not only spans a provincial border (Alberta and Saskatchewan) it also straddles time zones (Mountain and Central)...AND one province does DST (Alberta) and the other does not (Saskatchewan). Solution? The city officially does all business on Alberta time (IIRC--that being the physical location of city all..or perhaps because more of the population resides on the Alberta side).
All in all though, is one stupid our of daylight really worth the trouble? If it is so great, lets forget about "saving" our daylight and spend it all now by turning ahead an hour and STAYING there. I've already learned to live with closing all the blinds in my house so I can fall asleep at 10PM so I'll live with that...and furthermore though it'll be dusk, at least it won't be PITCH BLACK at 5 or 5:30 PM when I leave the office in December.
Any other Albertans (especially those in and around Lloyminster) care to start up a petition to send to Mr. Stelmach to universally adopt Saskatchewan time in Alberta? I'm sure there has to be a "green" argument for that.
Biggest problem is Java. For whatever reason, Sun decided to code its own DST routines instead of relying on the native OS routines. Stupid stupid stupid stupid Java.
Upgrading the JVM for production apps means full regression retesting. Sometimes upgrading appservers because they are incompatible with certain JVMs (stupid stupid stupid BEA).
Stupid stupid stupid stupid Java.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
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.
I haven't updated quite a while, that's when my glibc version I'm running was created, and my system passes the test!
date 032515002006
date 032515002007
Cool! Amazing Toys.
for a quick, Javascript-based test.