Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linux Systems and the New DST

kdawson posted more than 7 years ago | from the spring-forward-fall-flat dept.

Operating Systems 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."

Sorry! There are no comments related to the filter you selected.

Simple (4, Interesting)

SIGBUS (8236) | more than 7 years ago | (#18248612)

Set you system to run on UTC. No daylight savings hassles to worry about.

Re:Simple (0)

Anonymous Coward | more than 7 years ago | (#18248628)

A certain retarded system from a company that starts with the letter "M" can only run on local time...

Re:Simple (2, Informative)

GundamFan (848341) | more than 7 years ago | (#18248702)

A certain retarded AC has no idea how an OS that starts with a W works.

You can set a Windows box to GMT...

Re:Simple (0)

Anonymous Coward | more than 7 years ago | (#18248788)

And have it properly convert the time to the local time?

Re:Simple (1)

alexhs (877055) | more than 7 years ago | (#18248818)

Can you please let us know ?

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 (1)

TheThiefMaster (992038) | more than 7 years ago | (#18248662)

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.

Re:Simple (0)

Anonymous Coward | more than 7 years ago | (#18248686)

Thats what I do. But if you are a local timer and you forget to patch... Oh the horror, the clock will be out by an hour. geeee I think I'll change someone 4K to fix it.

Come on pople its not a big deal.

Re:Simple (3, Interesting)

toleraen (831634) | more than 7 years ago | (#18249330)

Come on pople its not a big deal.

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.)

Beware JVM Problems (5, Informative)

tritonman (998572) | more than 7 years ago | (#18248732)

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.

Re:Beware JVM Problems (1)

GunFodder (208805) | more than 7 years ago | (#18249416)

Why would anyone in their right mind still be using JVM 1.3?

Re:Beware JVM Problems (2, Informative)

Tony Hoyle (11698) | more than 7 years ago | (#18249558)

Proxy compatibility. MS Proxy server doesn't work with JVM 1.4 (and believe me there are still a lot of those around).

Not sure you'd see it in a home situation though.

Re:Simple (1)

sam0vi (985269) | more than 7 years ago | (#18248786)

Or people could disable daylight time savings and do it manually (with a mouse and a keyboard, i mean). Because what do you think are the computer tasks that would malfuncton because of an erratic time change? After all i dont know if servers can go down just because someone updates the system clock. Is a whole hour time change worse and changing it one second? So many questions, so much weed. cheers

A very simple *nix test (5, Informative)

Iphtashu Fitz (263795) | more than 7 years ago | (#18248622)

$ 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.

Re:A very simple *nix test (-1, Redundant)

mdsolar (1045926) | more than 7 years ago | (#18248750)

For some reason Gnome is no longer allowing pasting to an xterm so here is is your post again showing two dashes:
$ date --date="Mar 25 15:00:00 UTC 2006"
$ date --date="Mar 25 15:00:00 UTC 2007"

Works great. Thanks!

Re:A very simple *nix test (1)

0100010001010011 (652467) | more than 7 years ago | (#18248770)

Hurray for debian:

[~]: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) (3, Informative)

jmodule (609349) | more than 7 years ago | (#18248862)

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:A very simple *nix test (1)

Kyle_Katarn-(ISF) (982133) | more than 7 years ago | (#18248926)

openSUSE 10.1 comes up correctly out-of-the-box.

Thanks for the tip!

Looks like I'm screwed then (0)

Anonymous Coward | more than 7 years ago | (#18249070)

$ 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]

I don't even have that many options. (1)

oyenstikker (536040) | more than 7 years ago | (#18249286)

$ 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]

Try this (1)

mdsolar (1045926) | more than 7 years ago | (#18249498)

date -d "Mar 25 15:00:00 UTC 2006"
date -d "Mar 25 15:00:00 UTC 2007"

Paste it to a gnome terminal.

Win vs Lin (4, Informative)

stry_cat (558859) | more than 7 years ago | (#18248630)

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.

Re:Win vs Lin (4, Funny)

EveryNickIsTaken (1054794) | more than 7 years ago | (#18248742)

If you're competent in your Windows adminstration, then there isn't any danger of your entire system breaking.

Re:Win vs Lin (5, Insightful)

Anonymous Coward | more than 7 years ago | (#18248826)

If you're competent in your Windows adminstration, then there isn't any danger of your entire system breaking.


Exactly. All the competent Windows admins have already switched to Linux.

Re:Win vs Lin (1, Informative)

DrXym (126579) | more than 7 years ago | (#18248754)

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, 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.

Re:Win vs Lin (3, Insightful)

fbjon (692006) | more than 7 years ago | (#18248892)

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.

Re:Win vs Lin (0)

Anonymous Coward | more than 7 years ago | (#18249130)

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.

Well, for some applications, that would be wrong.

If you have a scheduling application, you want your meetings listed in local time. If you stored your meeting times in UTC, you would have incorrect values when you convert to local time. You also need to keep track of the timezone.

If I create 9 am meetings on march 9, march 13, march 29 and april 3, storing these values in UTC would give the wrong answer if the dates of DST change in the future.

Re:Win vs Lin (1)

Rob the Bold (788862) | more than 7 years ago | (#18249236)

If I create 9 am meetings on march 9, march 13, march 29 and april 3, storing these values in UTC would give the wrong answer if the dates of DST change in the future.

That assumes a rather naive UTC/LocalTime conversion.

Re:Win vs Lin (0)

Anonymous Coward | more than 7 years ago | (#18249446)

If I create 9 am meetings on march 9, march 13, march 29 and april 3, storing these values in UTC would give the wrong answer if the dates of DST change in the future.

That assumes a rather naive UTC/LocalTime conversion.


Not at all. Lets go back to 2004. You need to schedule meetings in 2007 at 9 am local time on march 9, march 13, march 29 and april 3. Your app converts these dates into UTC and stores the UTC values. For display purposes, your app converts the UTC values into local time. All is well.

Then, in 2005, in a flash of idiocy, the US congress decides to change the dates of DST. The zoneinfo files on your system get updated. Everything is good, right? Wrong.

Some of the stored UTC values for your meetings are now wrong. The only way you can tell which are wrong is if you knew the expected DST state in 2007 when the meeting was created back in 2004. If you only stored a single UTC value for the meeting, you don't know the when the meeting was created.

Simply storing date/time in UTC is not always sufficient.

wrong (1)

Reality Master 201 (578873) | more than 7 years ago | (#18249402)

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.

Re:Win vs Lin (1)

GunFodder (208805) | more than 7 years ago | (#18249488)

I used to agree with you, and storing dates in local time certainly makes it easier when viewing raw DB data. But eventually you run into issues when attempting to compare dates across TZs. In the end you will end up having to do TZ conversions on every date anyway, so you might as well keep everything in UTC to ensure that all stored dates can be easily compared.

Re:Win vs Lin (1)

DrXym (126579) | more than 7 years ago | (#18249160)

Sometimes you have to timestamp with whatever format the subsytem expects. Sometimes you have to assume the timezone of the timestamp because it doesn't say, or you have to convert because the system makes an assumption. Sometimes the subsystem is made by a 3rd party vendor or is otherwise physically out of your control.

It would be nice if you could dictate from end to end to use UTC but the real world doesn't always allow for it. And even if it did, you'd *still* need to verify your systems were DST compliant and patched so you're in the same mess either way.

Re:Win vs Lin (2, Interesting)

Bacon Bits (926911) | more than 7 years ago | (#18249316)

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 first place. Rather, for using timestamp without time zone, which, frankly, is absurd. Did they not expect email to be a global system?

Re:Win vs Lin (0)

Anonymous Coward | more than 7 years ago | (#18249270)

So what happens when I schedule a meeting in Germany and California and DST changes? What's the right one to move?

Re:Win vs Lin (1)

RealGrouchy (943109) | more than 7 years ago | (#18249520)

So what happens when I schedule a meeting in Germany and California and DST changes? What's the right one to move?

You'll have to coordinate that between the parties involved; a computer can't solve that for you.

- RG>

Re:Win vs Lin (1)

EvilRyry (1025309) | more than 7 years ago | (#18248914)

If the applications were correctly designed there is no issue when using Linux. Having the system clock on GMT works around a lot of the problems that Windows has with DST.

Re:Win vs Lin (0)

Anonymous Coward | more than 7 years ago | (#18248760)

Sounds like a pretty shitty admin you have over there. Our Exchange systems were updated without a hitch, and our setup is far from simple.

Re:Win vs Lin (0)

Anonymous Coward | more than 7 years ago | (#18248878)

So you're sure that Evolution / whatever other calendaring app you use will reliably keep all meetings at the correct time?

Re:Win vs Lin (0)

Anonymous Coward | more than 7 years ago | (#18248970)

Do Exchange-alternatives really work all that much better? How do they handle meeting with attendees in Germany?

Re:Win vs Lin (2, Insightful)

Anonymous Coward | more than 7 years ago | (#18249012)

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.

As much as I like linux, you are confusing two separate things: operating systems and applications. It is very easy to update windows to use the new DST rules. Frankly, even without patching, windows will not break, the clock will be off by an hour.

However, since exchange is (amongst other things) a calendaring application, all of the times of your schedule need to be checked if they are between the old DST change date and the new DST change date, and adjusted accordingly, otherwise your schedule will be off by an hour.

Microsoft has free tools & published procedures tools to update exchange. If you didn't follow them, that is your problem.

Re:Win vs Lin (-1, Troll)

Andrew Sterian (182) | more than 7 years ago | (#18249060)

If you want to see even more Win madness, take a look at these instructions [gvsu.edu] (in three phases) for dealing with the DST problem on a Novell GroupWise e-mail system.

What a nightmare! And that's just for one (closed source, painful to use) application.

Now if my university were running an open-source mail server with proven software (*cough* Slackware *cough*) the upgrade would have gone something like this:

wget 'ftp://ftp.slackware.com/pub/slackware/slackware-1 0.2/patches/packages/glibc-zoneinfo-2.3.5-noarch-7 _slack10.2.tgz' upgradepkg glibc-zoneinfo-2.3.5-noarch-7_slack10.2.tgz

NTP? (3, Interesting)

CarpetShark (865376) | more than 7 years ago | (#18248668)

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?

Re:NTP? (4, Informative)

overshoot (39700) | more than 7 years ago | (#18248704)

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?)

Re:NTP? (4, Informative)

E-Lad (1262) | more than 7 years ago | (#18248950)

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.

It probably should (1)

Kludge (13653) | more than 7 years ago | (#18249266)

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.

Re:NTP? (0)

Anonymous Coward | more than 7 years ago | (#18249026)

... does NTP all work on UTC so that it's not aware of this, or something?


That is correct, NTP is UTC. Most *nix kernels also keep track of time in UTC internally, it's just in userland where things are translated to the 'local' time. Each user (or even process) can have a different local time by simply setting the TZ environmental variable.

Personally I think we should get rid of timezones (and DST) all together: the time is the same regardless of where you are on the planet. It would simply mean that 5pm (17:00 UTC) would be breakfast in California, lunch-ish in New York, quitting time in London, bedtime in India. Though psychologically I think it would be very difficult for people to adapt.

Root Cause (5, Insightful)

overshoot (39700) | more than 7 years ago | (#18248676)

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?

Re:Root Cause (4, Insightful)

Rob the Bold (788862) | more than 7 years ago | (#18248734)

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.

Re:Root Cause (1)

mdboyd (969169) | more than 7 years ago | (#18248780)

You must want wine.woot [woot.com] too! The Horror! The Horror!

Re:Root Cause (1)

Phleg (523632) | more than 7 years ago | (#18248932)

So, for all of those who dislike DST, try this: Just get up an hour later.

I know you're just trying to be snarky, but that doesn't at all solve most people's problem with DST: the unneeded hassle, complication, and complete mess of having to deal with it. Even worse is when we make arbitrary changes to it, like this one.

Re:Root Cause (2, Interesting)

MrShaggy (683273) | more than 7 years ago | (#18249174)

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 solution. The other huge savings on the commute would be just to put six gears in everyones cars, this would allow the engine to run at a greatly reduced revolutions, putting out less pollution and using less gas over all. But try to say that to the big companies.

Re:Root Cause (1, Insightful)

Anonymous Coward | more than 7 years ago | (#18249112)

So, for all of those who dislike DST, try this: Just get up an hour later.
I found this quotation in the zoneinfo [twinsun.com] data file for North America:

I don't really care how time is reckoned so long as there is some agreement about it, but I object to being told that I am saving daylight when my reason tells me that I am doing nothing of the kind. I even object to the implication that I am wasting something valuable if I stay in bed after the sun has risen. As an admirer of moonlight I resent the bossy insistence of those who want to reduce my time for enjoying it. At the back of the Daylight Saving scheme I detect the bony, blue-fingered hand of Puritanism, eager to push people into bed earlier, and get them up earlier, to make them healthy, wealthy and wise in spite of themselves.
-- Robertson Davies, The Diary of Samuel Marchbanks, 1947, XIX, Sunday

Re:Root Cause (2, Insightful)

freeweed (309734) | more than 7 years ago | (#18249500)

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 have to change your watch to match. Going to UTC only works if you never ever leave your timezone - or else you'd have to be making on-the-fly calculations every time you tried to remember what time the movie is at, or when the store closes, or what have you. Having a common time reference point means never having to worry about "hmm, when exactly is 5pm now that I'm on the other coast?".

I've never understood why people think DST is "complicated". Shift your clocks twice a year (takes me all of 10 seconds as the computers take care of the rest). That extra hour of daylight after work is seriously awesome. Everyone, after about a day, adjusts and retains the same 24 hour cycle we run on - office hours are typically 9-5, at midnight odds are it will be pitch black out, that sort of thing.

Honestly, if getting up an hour earlier for one day in April (now March) messes with your internal clock THAT much, I shudder to think what life would be like when you have children.

Re:Root Cause (1)

Bios_Hakr (68586) | more than 7 years ago | (#18248850)

I hated DST till I came to Japan.

I usually get off work at 5pm. Sometimes 6ish. In the US, I have summer daylight till almost 10pm. I can cut my grass, swim a little, play some frisbee, and still cook burgers and dogs before dark.

In Japan, the first thing is that the sun comes up at like 4am. It's usually light by 3:30am and full sun my 4:30am. Sleeping in requires blackout devices on the windows.

Then, when you finally get home, you have, at best, 2 hours of light. Sun's down by 7pm and it's dark by 8pm.

I'll take the mild irritation of resetting my watch twice a year to have that extra sun in the afternoon.

Re:Root Cause (1)

Waffle Iron (339739) | more than 7 years ago | (#18249036)

Even without DST, timezone boundaries are still arbitrary political definitions that occasionally get changed. No matter what, it's not a good idea to hard-code timezone information. DST and changes to it are a good thing because they force developers to remember not to hard code time info, thus avoiding much larger problems if timezone changes were very infrequent and everything drifted into being hard coded. This is like a booster shot for a vaccine; it may hurt a little, but in the end it's good for you.

Re:Root Cause (0)

Anonymous Coward | more than 7 years ago | (#18249152)

Abolish DST!!

Impeach Bush! (1)

Black-Man (198831) | more than 7 years ago | (#18249478)

WTF was he thinking? This has been a big cluster and has sucked IT resources for the past month.

Re:Root Cause (1)

tuffy (10202) | more than 7 years ago | (#18249512)

Perhaps I can pressure my legislature to provide magic fairies who will change my clocks when the need arises.

The fact is, DST is not going away. Even if it disappears in some territories, it's safe to assume it will not disappear from all of them in our lifetimes. Thus, we're still going to have to deal with it on our computer systems. And so the constant calls of "abolish DST" remain entirely unhelpful.

Re:Root Cause (0)

Anonymous Coward | more than 7 years ago | (#18249522)

DST's real purpose is so that those of us who don't fly can still experience the joys of jetlag twice a year.

The Department of Homeland Security is working on the "joys of taking off your shoes, going through metal detectors, and possibly being body-cavity searched" for those of us who don't fly, as well. Give them time.

Simple (1)

isj (453011) | more than 7 years ago | (#18248680)

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.

Re:Simple (0)

Anonymous Coward | more than 7 years ago | (#18248776)

What? They have linux is Antarctica right? Oh wait, yeah.. the time thing, right. I'll change my linux box tonight or something manually.

Re:Simple (1)

Teun (17872) | more than 7 years ago | (#18248930)

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.
Ah yes, then Tux himself can fix it!

Though it might be more convenient to get to see him at the local Zoo.

Re:Simple (1)

TWX (665546) | more than 7 years ago | (#18249246)

Or move to Arizona, as we don't observe Daylight Savings Time at all... It's nice not having to deal with that BS...

Better article (2, Informative)

grimwell (141031) | more than 7 years ago | (#18248728)

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.

Let the circus begin (2, Insightful)

phoenixwade (997892) | more than 7 years ago | (#18248736)

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.

Re:Let the circus begin (1)

mhall119 (1035984) | more than 7 years ago | (#18249508)

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.

Or fighter jets losing all navigation and communication systems mid-flight [slashdot.org] ?

Shouldn't that be... (1)

Glowing Fish (155236) | more than 7 years ago | (#18248738)

Shouldn't that be the Y2K7DST Bug?
Or can we come up with an even more involved name?

Re:Shouldn't that be... (1)

Bob54321 (911744) | more than 7 years ago | (#18248764)

Shouldn't that be the Y2K7DST Bug?
Or can we come up with an even more involved name?

Well, actually spelling out the words would be a start...

Y2K7DSTOMGWTFBBQApocalypse!!!!!1 (0, Funny)

Anonymous Coward | more than 7 years ago | (#18249146)

There. That should do it.

Late in the game? (1)

XenoPhage (242134) | more than 7 years ago | (#18248814)

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*

Re:Late in the game? (1)

Iphtashu Fitz (263795) | more than 7 years ago | (#18248886)

Virtually all the versions of linux my company is using in production already contains the correct tzdata. (Centos 4.2 & later, RHEL 4 & later, etc.) The versions of Java we've also been using for close to a year are also properly updated. Sun has provided a program to test older versions of java and patch them if necessary. It's on their website for download.

We're not all that concerned about network devices like firewalls, switches, etc. The only time sensitive data they have are logs, and since we use a centralized syslog server that's already up-to-date it's not a major issue for us. Our switch/firewall vendors provide information on setting up custom timezone settings, which means its a fairly simple thing to change. No need to apply patches that could impact performance or behavior.

Re:Late in the game? (1)

Rob the Bold (788862) | more than 7 years ago | (#18249296)

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.

Forget patches. I wonder why anyone is still building systems that have DST hard-coded into them. DST definitions vary by country and can be changed by government action. Even in the US, DST definitions were changed less than 20 years ago.

Re:Late in the game? (2, Interesting)

rwhiffen (141401) | more than 7 years ago | (#18249312)

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.

Further, if your running Solaris it's not just a TZ patch. There's libc changes:

http://src.opensolaris.org/source/diff/onnv/onnv-g ate/usr/src/lib/libc/port/gen/localtime.c?r1=1138& r2=0 [opensolaris.org]

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 [redhat.com]

Cheers,
Rich

Re:Late in the game? (1)

operagost (62405) | more than 7 years ago | (#18249578)

HP refused to release the OpenVMS patches until late last year, and even then they put in a bomb to abort the installation if the system date wasn't in 2007. Supposedly, this was to keep people from installing the patch before the 2006 DST-STD time switch. But that doesn't make any sense because two out of the three versions of VMS that were patched use the standard tables, which include historical data so that even if you wanted to party like it's 1999 the date would switch properly.

Stupid saying... (1)

advocate_one (662832) | more than 7 years ago | (#18248822)

"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...

I alwasy thought that too. (0)

Anonymous Coward | more than 7 years ago | (#18249200)

Never made sense.

Re:Stupid saying... (0)

Anonymous Coward | more than 7 years ago | (#18249206)

Since when does anybody 'spring back'? Sure, the sentence is grammatically legitimate either way, but it is definitely more plausible to spring forwards than backwards.

DST in Australia (1)

mab (17941) | more than 7 years ago | (#18248830)

Australia went though this last year and as far as I know it went smoothly http://www.sbsusers.org/melbourne/alerts7.htm [sbsusers.org]

Re:DST in Australia (0)

Anonymous Coward | more than 7 years ago | (#18249134)

It went terribly.

The state government involved passed the legislation just a few days before the change was due to take effect. There wasn't a patch for Exchange: things just broke. I don't think RIM released one either, and I doubt they were the only ones. The Australian case is a great example of how NOT to fiddle with DST.

This changeover should have been a lot easier: the affected market is much larger and the lead time was substantial. I find it incredible that many vendors have only recently released patches. Even worse, one of the most important MS patches seems to contain unrelated code changes (KB926666 can stop your Exchange information store starting - i.e., it can break Exchange, and then requires another patch to get it working again).

Re:DST in Australia (1)

deniable (76198) | more than 7 years ago | (#18249268)

That sounds like last December in Western Australia. Two political has-beens needed to fix their image so they decided we needed DST.

Consider waking up and having the radio tell you that we'll start doing DST on Sunday and our last "trial" was 15 years ago. I stayed unemployed for that one.

And as for Exchange, anything can make your IS refuse to restart, and updating it can require good luck and strong nerves.

emerge -u world (1)

garlicbready (846542) | more than 7 years ago | (#18248894)

lets see now...
emerge -u world
yep that should do it
and relax

Re:emerge -u world (0)

Anonymous Coward | more than 7 years ago | (#18248982)

That's a long time to relax before you can use your system again...

How may we help you? (4, Funny)

djupedal (584558) | more than 7 years ago | (#18248934)

"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......."

Re:How may we help you? (-1)

Anonymous Coward | more than 7 years ago | (#18249064)

I wish I had mod points.

Re:How may we help you? (1, Informative)

Anonymous Coward | more than 7 years ago | (#18249252)

"Microsoft - I see. Well, Stuart, the big hand is on the four and the little hand is......."

If it's 4:42, wouldn't the big hand be closer to the 8?

How to verify whether your system is up to date (3, Informative)

E-Lad (1262) | more than 7 years ago | (#18249020)

Use the zdump command:

zdump -v [timezone] | grep 2007
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.

Re:How to verify whether your system is up to date (1)

noc007 (633443) | more than 7 years ago | (#18249154)

The command works on our FreeBSD systems as well.

A problem with DST in general (3, Insightful)

Bigmilt8 (843256) | more than 7 years ago | (#18249054)

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.

DST has its place. (1)

lstellar (1047264) | more than 7 years ago | (#18249234)

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.

You can blame reagan for that nightmare (1, Interesting)

Anonymous Coward | more than 7 years ago | (#18249524)

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.

Easy way to tell if you're patched... (-1, Redundant)

IGnatius T Foobar (4328) | more than 7 years ago | (#18249150)

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.

To see if you're patched... (1)

IGnatius T Foobar (4328) | more than 7 years ago | (#18249184)

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.

Setting DST on older RedHat systems (2, Informative)

yuna49 (905461) | more than 7 years ago | (#18249196)

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.

The short answer... (3, Informative)

pla (258480) | more than 7 years ago | (#18249202)

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):

cd /tmp
wget --passive-ftp ftp://elsie.nci.nih.gov/pub/tzdata2007c.tar.gz [nih.gov]
tar -xzvf tzdata2007c.tar.gz
zic northamerica
ln -sf /usr/share/zoneinfo/EST5EDT /etc/localtime

If you live outside the civilized world, insert the appropriate time zone in place of EST5EDT. ;-)

And finally, verify it with:
zdump -v /etc/localtime | grep 2007
Which should say "Mar 11" and "Nov 4"

Just hire a few brazilians (2, Interesting)

pazu (99303) | more than 7 years ago | (#18249274)

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 [microsoft.com] .

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 :)

For Slackware 11 users... (1)

Noryungi (70322) | more than 7 years ago | (#18249284)

This change is covered in the glibc-zoneinfo-2.3.6-noarch-7_slack11.0.tgz [slackware.it] 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...

Think of Canada, eh (1)

RabidMonkey (30447) | more than 7 years ago | (#18249308)

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.

I'm worried... (3, Insightful)

FuzzyDaddy (584528) | more than 7 years ago | (#18249338)

I have an international flight on Monday the 12th.

I'm coming four hours early.

Re:I'm worried... (0)

Anonymous Coward | more than 7 years ago | (#18249454)

I'm coming four hours early.
Don't the commercials warn you to seek medical treatment for that?

Recent? It was two years ago... (4, Insightful)

binaryspiral (784263) | more than 7 years ago | (#18249366)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?