Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Linux Systems and the New DST

Posted by kdawson on Tue Mar 06, 2007 08:58 AM
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."
+ -
story

Related Stories

[+] Technology: 'Daylight Savings Bugs' Loom 403 comments
An anonymous reader writes "ZDNet has front page coverage of the looming daylight savings changeover, and the bugs that may crop up this year. With the extension of daylight savings time by four weeks, some engineers and programmers are warning that unprepared companies will experience serious problems in March. While companies like Microsoft have already patched their software, Gartner is warning that bugs in the travel and banking sectors could have unforeseen consequences in the coming months. ' In addition, trading applications might execute purchases and sales at the wrong time, and cell phone-billing software could charge peak rates at off-peak hours. On top of that, the effect is expected to be felt around the world: Canada and Bermuda are conforming to the U.S.-mandated change, and time zone shifts have happened in other locales as well.'" Is this just more Y2K doomsaying, or do you think there's a serious problem here?
[+] Microsoft Charging Businesses $4K for DST Fix 395 comments
eldavojohn writes "Microsoft has slashed the price it's going to charge users on the daylight saving time fixes. As you know, the federal law that moves the date for DST goes into effect this month. Although the price of $4000 is 1/10 of the original estimate Microsoft made, it seems a bit pricey for a patch to a product you've already paid for. From the article: 'Among the titles in that extended support category are Windows 2000, Exchange Server 2000 and Outlook 2000, the e-mail and calendar client included with Office 2000. For users running that software, Microsoft charges $4,000 per product for DST fixes. For that amount, customers can apply the patches to all systems in their organizations, including branch offices and affiliate.' The only thing they can't do, said a Microsoft rep, is redistribute them."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • Simple (Score:5, Interesting)

    by SIGBUS (8236) on Tuesday March 06 2007, @09:02AM (#18248612) Homepage
    Set you system to run on UTC. No daylight savings hassles to worry about.
    • Beware JVM Problems (Score:5, Informative)

      by tritonman (998572) on Tuesday March 06 2007, @09: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.
      • Re: (Score:3, Informative)

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

        by toleraen (831634) on Tuesday March 06 2007, @10:38AM (#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.)
        • by GodWasAnAlien (206300) on Tuesday March 06 2007, @12:13PM (#18250440)
          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?".

  • by Iphtashu Fitz (263795) on Tuesday March 06 2007, @09: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, @09: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.
    • by EveryNickIsTaken (1054794) on Tuesday March 06 2007, @09: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, @09: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:Win vs Lin (Score:4, Insightful)

        by fbjon (692006) on Tuesday March 06 2007, @09: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.
                  • To give you an example of a meeting that spans several timezones; we needed to hold a teleconference with people in the UK, Australia and the US. Within the US, a company with offices in New York and San Francisco faces the same issue; you have people in different timezones, who need to agree on a time.

                    It's not possible to get a perfect solution to the problem. The best design I've seen stores times in UTC, together with a description of the entry timezone and the offset. Each user has a current local timezone (and it's assumed that users who travel will track these problems for themselves). When a change to DST comes along, the administrator can do some or all of the following:

                    • Adjust meetings such that meetings entered in the timezone that's changing are at the same local time (but a different UTC time).
                    • Adjust meetings such that meetings entered in the timezone that's changing are at the same UTC time (but a different local time).
                    • Alert everyone who's involved with a meeting where one or more participants are in a timezone that's changing to check that the time is still valid.

                    The system also allows users to override the entry timezone on a per-entry basis. This means that I can enter a meeting in the UK marked as 9am Atlanta time, and be confident that it'll not only appear properly, but that if Atlanta's timezone changes on me, it'll be updated properly.

  • NTP? (Score:4, Interesting)

    by CarpetShark (865376) on Tuesday March 06 2007, @09: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, @09: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, @09:55AM (#18248950) Homepage
      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.

  • Root Cause (Score:5, Insightful)

    by overshoot (39700) on Tuesday March 06 2007, @09: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, @09: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.

  • Better article (Score:3, Informative)

    by grimwell (141031) on Tuesday March 06 2007, @09: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.
  • by djupedal (584558) on Tuesday March 06 2007, @09: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......."
  • by E-Lad (1262) on Tuesday March 06 2007, @10:02AM (#18249020) Homepage
    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.
  • The short answer... (Score:4, Informative)

    by pla (258480) on Tuesday March 06 2007, @10: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"
  • I'm worried... (Score:4, Insightful)

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

    I'm coming four hours early.

  • by binaryspiral (784263) on Tuesday March 06 2007, @10: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.
    • by westlake (615356) on Tuesday March 06 2007, @11: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.