Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Linux

Linux Systems and the New DST 304

Posted by kdawson from the spring-forward-fall-flat dept.
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."
This discussion has been archived. No new comments can be posted.

Linux Systems and the New DST More

Linux Systems and the New DST

Comments Filter:

  • Simple (Score:5, Interesting)

    by SIGBUS ( 8236 ) on Tuesday March 06, 2007 @08:02AM (#18248612) Homepage
    Set you system to run on UTC. No daylight savings hassles to worry about.
    • 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.

    • Beware JVM Problems (Score:5, Informative)

      by tritonman ( 998572 ) on Tuesday March 06, 2007 @08:21AM (#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.
      • Why would anyone in their right mind still be using JVM 1.3?

        • Re: (Score:3, Informative)

          by Tony Hoyle ( 11698 )
          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: (Score:3, Informative)

        by twivel ( 89696 )
        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

  • A very simple *nix test (Score:5, Informative)

    by Iphtashu Fitz ( 263795 ) on Tuesday March 06, 2007 @08:04AM (#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.

  • Win vs Lin (Score:5, Informative)

    by stry_cat ( 558859 ) on Tuesday March 06, 2007 @08:05AM (#18248630) Journal
    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 (Score:5, Funny)

      by EveryNickIsTaken ( 1054794 ) on Tuesday March 06, 2007 @08:22AM (#18248742)
      If you're competent in your Windows adminstration, then there isn't any danger of your entire system breaking.

      • Re:Win vs Lin (Score:5, Insightful)

        by Anonymous Coward on Tuesday March 06, 2007 @08:38AM (#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: (Score:2, Informative)

      by DrXym ( 126579 )
      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

      • Re:Win vs Lin (Score:4, Insightful)

        by fbjon ( 692006 ) on Tuesday March 06, 2007 @08:48AM (#18248892) Homepage Journal
        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: (Score:2)

          by DrXym ( 126579 )
          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 comp

          • Re: (Score:3, Interesting)

            by Bacon Bits ( 926911 )
            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
          • "Sometimes you have to timestamp with whatever format the subsystem expects."

            As an alternative, you could include timezone offsets with local time.

            2007-03-06 07:30:00 -0800.

            This is how email is stamped.

            Then you are effectively passing both local time and UTC.
            That way, the "subsystem" can effectually correct the bug and use effective UTC for calculations.

            07:30 - (-08:00) = 15:30:00

            BTW, I wish slashdot would display dates with timezone offsets.

            But slashdot, has yet to fix use of Y99 dates.
            ( http ://linux.sla

    • Re: (Score:2, Insightful)

      by Anonymous Coward
      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
  • I'm so glad Micro$oft in on top of this. Oh, wait....
    --
    Real daylight savings: http://mdsolar.blogspot.com/2007/01/slashdot-users -selling-solar.html [blogspot.com]

  • NTP? (Score:4, Interesting)

    by CarpetShark ( 865376 ) on Tuesday March 06, 2007 @08:12AM (#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? (Score:5, Informative)

      by overshoot ( 39700 ) on Tuesday March 06, 2007 @08:17AM (#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? (Score:5, Informative)

      by E-Lad ( 1262 ) on Tuesday March 06, 2007 @08:55AM (#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.

      • 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.
        • And hopefully avoid confusion like wehave now...

          The time zones "(GMT-8)Pacific; Tijuana" and "(GMT-8)Tijuana" are now different. (or will be in a week)

          I wasted about 6 hours of testing, frustrated that the patches weren't working on a Windows test environment before noticing that I had teh wrong timezone. (And I'm only a short drive from Tijuana...)

        • Re: (Score:3, Insightful)

          by Viol8 ( 599362 )
          And what happens if someone if one country/state wants to connect to an NTP server in another? If that NTP server only gives its local time then that computer will get the wrong time and if it gives all timezone times then not only will it send FAR more data but you'll STILL have to set the timezone in your machine anyway so it can select the correct one from NTP.

          So I'm afraid your idea is a non starter.

  • Root Cause (Score:5, Insightful)

    by overshoot ( 39700 ) on Tuesday March 06, 2007 @08:13AM (#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 (Score:5, Insightful)

      by Rob the Bold ( 788862 ) on Tuesday March 06, 2007 @08:21AM (#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: (Score:2)

        by Phleg ( 523632 )

        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: (Score:3, Interesting)

          by MrShaggy ( 683273 )
          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
          • Remember, DST came from a guy who lit a candle in his widow before dawn to give the impression he was working hard.

            [...]but Dr. Baird (whom you and I saw many years after at his native place, St. Andrew's in Scotland) gave a contrary opinion: "For the industry of that Franklin," says he, "is superior to any thing I ever saw of the kind; I see him still at work when I go home from club, and he is at work again before his neighbors are out of bed."

            http://odur.let.rug.nl/~usa/B/bfranklin/franktxt.h tm [let.rug.nl]

            That

      • Re: (Score:3, Insightful)

        by freeweed ( 309734 )
        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?

          And d

      • Re: (Score:2)

        by CompMD ( 522020 )
        My mystical crystal ball says you live in Kansas City, Kansas. :)

      • Re: (Score:2)

        by mgblst ( 80109 )
        I like having an excuse to rock up an hour late to work, once a year. Well, a different excuse.
    • 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 8
    • 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.
    • WTF was he thinking? This has been a big cluster and has sucked IT resources for the past month.

    • Re: (Score:2)

      by tuffy ( 10202 )

      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.

    • Just program clocks to adjust the time so that the sun rises at the exact same time every morning.

  • Simple (Score:2)

    by isj ( 453011 )
    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: (Score:2)

      by Teun ( 17872 )

      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: (Score:2)

      by TWX ( 665546 )
      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 (Score:3, Informative)

    by grimwell ( 141031 ) on Tuesday March 06, 2007 @08:21AM (#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.
  • 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.
  • Shouldn't that be the Y2K7DST Bug?
    Or can we come up with an even more involved name?
  • 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
    • 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 si

    • 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 ac

    • Re: (Score:2, Interesting)

      by rwhiffen ( 141401 )
      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
    • 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.
  • "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...
    • How often do you hear of someone springing backward or falling forward? But there are many instances where someone falls back (retreats) or springs forward.

      Springing backward seems to have a high risk for injury...

    • Re: (Score:2)

      by Cheapy ( 809643 )
      Last time I checked, one "springs" forward. As in jumps forward. And one "falls" backwards. I'm not quite sure how one would "spring" backwards. Although that would be highly amusing to watch on youtube.

  • How may we help you? (Score:5, Funny)

    by djupedal ( 584558 ) on Tuesday March 06, 2007 @08:54AM (#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......."

  • How to verify whether your system is up to date (Score:4, Informative)

    by E-Lad ( 1262 ) on Tuesday March 06, 2007 @09:02AM (#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.

  • A problem with DST in general (Score:3, Insightful)

    by Bigmilt8 ( 843256 ) on Tuesday March 06, 2007 @09:06AM (#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.

    • Re:A problem with DST in general (Score:4, Informative)

      by westlake ( 615356 ) on Tuesday March 06, 2007 @10:51AM (#18250152)
      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.

  • 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 appropriat

  • Setting DST on older RedHat systems (Score:3, Informative)

    by yuna49 ( 905461 ) on Tuesday March 06, 2007 @09:23AM (#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... (Score:4, Informative)

    by pla ( 258480 ) on Tuesday March 06, 2007 @09:24AM (#18249202) Journal
    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 (Score:2, Interesting)

    by pazu ( 99303 )

    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 th

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

    • Re: (Score:2, Funny)

      by Skater ( 41976 )
      Yeah, we're here, but we already installed the update without fanfare and are now chuckling at the angst in some of the posts in this article. :)

      In fact, my server is still running 10.2 and Patrick has released a patch for that version as well, and probably a few others.

      • Re: (Score:2)

        by Noryungi ( 70322 )

        Yeah, we're here, but we already installed the update without fanfare and are now chuckling at the angst in some of the posts in this article. :)

        I should have guessed... :-)

        In fact, my server is still running 10.2 and Patrick has released a patch for that version as well, and probably a few others.

        Yep, The Man is still on top of things.
  • 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

  • I'm worried... (Score:4, Insightful)

    by FuzzyDaddy ( 584528 ) on Tuesday March 06, 2007 @09:39AM (#18249338) Journal
    I have an international flight on Monday the 12th.

    I'm coming four hours early.

    • I have an international flight on Monday the 12th.
      I'm coming four hours early.
      You're adding an extra two hours? At worst wouldn't it be off by one hour?

  • Recent? It was two years ago... (Score:5, Insightful)

    by binaryspiral ( 784263 ) on Tuesday March 06, 2007 @09:42AM (#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.
  • $packagemanager $updaterepository && $packagemanager $installupdates

    Or a real-world example for gentoo, which takes approx. 15 minutes:
    emerge --sync && emerge -u tzcode tzdata
  • 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.

    The following link provides good information for patching Java from the 4 major java providers.

    http://www.javasanity.org/article/3/dst-and-java-d ont-panic-it-can-be- [javasanity.org]

  • FreeBSD howto (Score:3, Informative)

    by jefp ( 90879 ) <jef@mail.acme.com> on Tuesday March 06, 2007 @12:11PM (#18251322) Homepage
    I did my old FreeBSD systems yesterday. The procedure was as follows:

    1) Fetch the new rules file. I got it from:
              http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/s rc/share/zoneinfo/northamerica?rev=1.31 [freebsd.org]

    2) Save it as /usr/src/share/zoneinfo/northamerica

    3) In /usr/src/share/zoneinfo do a 'make install' - this compiles the rules into /usr/share/zoneinfo/.

    4) Run tzsetup - this copies the proper file from /usr/share/zoneinfo/ to /etc/localtime.

    5) Do a 'locate localtime' to see if you have any copies of /etc/localtime in chroot trees, e.g. /etc/bind/. If so, copy the new one there too.

    If you have multiple identical systems you can do this on one and then copy the new /etc/localtime to the rest.

  • I wonder (Score:3, Insightful)

    by ajs318 ( 655362 ) <.sd_resp2. .at. .earthshod.co.uk.> on Tuesday March 06, 2007 @12:20PM (#18251470)
    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.

  • FYI, Red Hat's Patch is Incorrect! (Score:3, Informative)

    by h4ck7h3p14n37 ( 926070 ) on Tuesday March 06, 2007 @05:56PM (#18256108) Homepage

    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.

Slashdot Top Deals

Real Programmers think better when playing Adventure or Rogue.

Close