Forgot your password?
typodupeerror
Programming Software Technology IT

'Daylight Savings Bugs' Loom 403

Posted by Zonk
from the crush-those-critters dept.
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?
This discussion has been archived. No new comments can be posted.

'Daylight Savings Bugs' Loom

Comments Filter:
  • by suso (153703) * on Friday February 16, 2007 @01:09PM (#18040026) Homepage Journal
    http://www.bloomingtonlinux.org/wiki/DST_Time_Chan ge_Issues [bloomingtonlinux.org]

    A year ago, after most of Indiana went through its first timezone change in 40+ years, we found out that it presented a few problems in Linux, I tried to post a story to Slashdot about it to warn other people in the US that they would be dealing with this problem later when the rest of the US changes to the new DST. I tried several times to post it and they were all rejected.

    Basically, you need to make sure that if you change your timezone data on your system that you restart everything, otherwise when the time does change, some programs continue to use the old timezone data and are an hour off.
    • by Anonymous Coward on Friday February 16, 2007 @01:16PM (#18040170)

      A year ago, after most of Indiana went through its first timezone change in 40+ years, we found out that it presented a few problems in Linux, I tried to post a story to Slashdot about it to warn other people in the US that they would be dealing with this problem later when the rest of the US changes to the new DST. I tried several times to post it and they were all rejected.
      Mod parent down, informative.
    • Re: (Score:3, Informative)

      by jcgam69 (994690)
      We're already having serious problems with this change. Patched windows workstations show different appointment times than unpatched workstations. We're planning to roll out the windows patch, http://support.microsoft.com/kb/928388 [microsoft.com], to all computers ASAP.
    • by Ubergrendle (531719) on Friday February 16, 2007 @01:20PM (#18040256) Journal
      Our datacentre has ~ 500 Solaris / HP-UX / AIX boxen, and ~ 1000 Windows servers.

      15 minute change window to apply patch, another 15 minutes to reboot successfully and come back online. Multiply 30 min x 1500 = 45,000 minutes, or 750 hours. But we only have one weekly change window, Sunday mornings from 2-6am. Assuming finite number of staff, contingency (there's always going to be some problems), etc... we started last September. We might just make the deadline.

      So yes, I think its a bit of a problem. There's also the unspoken assumption that people learned their lessons during Y2k and have sufficient date handling logic to address changes to DST...nothing hard coded in the underlying applications.

      • by shawn(at)fsu (447153) on Friday February 16, 2007 @01:33PM (#18040486) Homepage
        Multiply 30 min x 1500 = 45,000 minutes, or 750 hours
        Yeah that sounds about right if you do each machine one at a time. I should hope a datacentre is a little more efficient than that.
        • Re: (Score:3, Informative)

          by danielblair (637546)

          Amen!

          Seagate [seagate.com] and Peregrine/HP [peregrine.com] have some really nice, robust, Data Center Management software for managing 10s, 100s, or even thousands of computers and the software on them... you can push, say, SP2 to all 5000 machines, and it's like a few clicks to do it.. and it takes care of everything! Then you check the error report, etc. to make sure that none of the known machines encountered an error (or were turned off at the time), and then you address them individually...

          With the # of servers that you a

      • Re: (Score:3, Insightful)

        by gclef (96311)
        You have approximately 1500 servers, and you're not automating patches and server management...exactly...why?

        Applying the patch to systems in batches is totally reasonable (if something goes wrong, you limit the number of explosions you're dealing with at any one time). Doing them all by hand, one by one, is totally insane.
      • by Threni (635302) on Friday February 16, 2007 @03:44PM (#18042780)
        > 15 minute change window to apply patch, another 15 minutes to reboot successfully and come back
        > online. Multiply 30 min x 1500 = 45,000 minutes, or 750 hours

        Yeah, someone needs to tell my local cinema about that. They only show films for a few weeks, but with 1000 people in each showing, and the film lasting 90 minutes, that's 90,000 minutes, or nearly 9 weeks! There's going to be a lot of disappointed people...
      • Re: (Score:3, Informative)

        Add 8-10 JRE's per server, versions 1.3.x through 1.5.x and a different JRE updater for each vendor, the upcoming MSVCRT.DLL updates and it quickly becomes a huge world of hurt.

        The Sun JRE updater has to be run on each installed version of the JRE. Remove the old ones? Not a chance - could break an app. What about 1.3, well, you're SOL.

        IBM thought they were brilliant with their 1.4 & 1.5 implimentation - They roll the ZI info into the Core.JAR file. No one will monkey with it there. Their updater u
    • Re: (Score:3, Insightful)

      by vadim_t (324782)
      Why do your programs use the local timezone, anyway?

      Programs should handle and store dates in UTC, and convert to the local timezone only for display.
      • Re: (Score:3, Informative)

        by VertigoAce (257771)
        The thing that I've seen warnings about is people trying to schedule meetings/events/etc that happen during the time between the new and old time changes. Generally you schedule something with respect to local time, but the program itself stores it as UTC (as you suggest). If you scheduled it on an unpatched machine, it would be an hour off when you got around to patching the machine.
      • by Marillion (33728) <ericbardesNO@SPAMgmail.com> on Friday February 16, 2007 @02:15PM (#18041296)

        Most programs that use the standard C library do use UTC and just don't realise it. The most important thing to realise about daylight savings time is that Time isn't changing. The sun still rise the after DST as before DST (astronomical adjustments due to Earth's heliocentric orbit not withstanding). But, how we read the clock is changing.

        I heard one company just say, "we're going to just change the clock on the computer." This makes me cringe.

        All file time timestamps on all versions of UNIX and versions of Windows derived from NT store times as Julian seconds since 1970-01-01 00:00:00 GMT. Changing the system clock means that the times will be stored wrong even though they display properly in the local timezone.

        Other places to watch out for are applications that manage their own timezone data. Java is a prime example. Major database vendors would be another.

        • by pe1chl (90186) on Friday February 16, 2007 @02:32PM (#18041666)
          When you are so careful about file timestamps, you should know that Windows does not translate them correctly anyway.
          Windows has no knowledge about timezone history. It translates the UTC time to local time using its current time-offset, which depends on the current DST status only.
          So, when you now look at a file timestamp (in the GUI) that you created last summer, you will find that its time is one hour off.

          Even when Microsoft would finally fix this (they consider it a feature rather than a bug), they would probably not fix the historic aspect.
          I.e. now that the beginning of DST shifts one month, and you would look at a file created last year in that one month window, it would probably still be off.

          Timezone handling in Windows just sucks. It does not have to be that bad, it works fine in Linux (including historic changes). Microsoft just has decided to make a bad implementation and then never fix it, in the name of backward compatability.
      • Not that simple. (Score:3, Interesting)

        by centron (61482)

        It would be nice if it were that simple. Take, for example, a cell phone billing system since that is referenced in the article. When bill processing happens, the actual time of the call needs to be on the bill. Customers wouldn't be too happy if all the call times were in GMT, would they? So the GMT values stored in the database need to be compared against a table that tells it what offset to apply to the time, based on the time and date the call was made. If that table isn't updated with new start and end

      • by tushar (205002) on Friday February 16, 2007 @03:04PM (#18042174)

        Why do your programs use the local timezone, anyway? Programs should handle and store dates in UTC, and convert to the local timezone only for display.
        Saving the time in UTC does not get rid of all problems. Programs that store the data for future events will still run into issues. An event that was stored in the database before the system was patched will be off by one hour if the time falls within the dates that have the daylight savings rule changed.
  • by TinBromide (921574) on Friday February 16, 2007 @01:13PM (#18040094)
    The reason y2k was such a letdown was because everybody took heed of the media hype and patched their stuff. If there had been no hype before, there might have been the problems that the hype was warning about. (or not, sensationalism is sensationalism)

    Its like you're driving along and there's a huge backup for miles because of an accident in the middle of the road after a bend. Now this huge backup may have slowed you down and made you aware that there was a problem. If it was just you and the wreck, you may have plowed into it if you weren't paying attention.

    Same thing with this hype. We should tolerate the hype because the heightened coverage will get bosses talking to programmers about fixing the software, and it'll turn out to be nothing.
    • Mod Parent Up (Score:3, Insightful)

      Absolutely.

      Most people look back at Y2K as fear mongering. Nothing catastrophic happened, therefor it was all a media hoax. BS. Nothing happened because it an urgent fear while there was still enough time to fix it, and alot of people put alot of effort into getting all the critical software patched.

      • Re: (Score:3, Interesting)

        by mike2R (721965)
        But what you are asking us [ie people who know crap all about Y2K] to believe is that the fear was so intense that every important computer system everywhere was patched. The obvious doubt is that this seems very unlikely; that kind of efficiency is not frequent in human affairs.

        Since the only people who really know about it are the people who made money out of it, it's hard to accept a claim of "we all just did our jobs and saved the world."
    • by DrXym (126579) on Friday February 16, 2007 @01:55PM (#18040910)
      I think y2k was a let down because it was fairly straightforward to fix software and tell if it was going to get bitten or not. Basically anything that stored dates as two digits had to be fixed. The bigger problem will come in 2037 when lots of clunking software with no source code wraps around.

      The DST thing is pretty evil too because it's usually up to runtime stacks like Java and CRT to decide on the timezone and time. If they give you the wrong time you're screwed. For the most part you might be okay if everything resolves down to some registry entries or timezone data files but that isn't always the case. There are functions such as Microsoft's _tzset() which are HARDCODED to a particular behaviour and apps that link to the CRT or have their own DLLs will be broken unless you recompile them.

      • by h2g2bob (948006) on Friday February 16, 2007 @02:27PM (#18041594) Homepage
        Mod parent up!

        Changing daylight savings time or y2k will be childsplay compared to the Year 2038 32-bit time_t overflow [wikipedia.org]. That is a really big problem with no easy fix. 32-bit times/dates are in everything from VCRs and microwaves to servers and desktops. 2038 will be everything that Y2K wasn't.

        In principle, Linux and friends can fix this by redefining time_t to 64-bit - but lots of communication protocols and even file formats like tar use 32-bit dates. Admittedly we have 30 years to fix it, but we will need all 30.
  • rates? (Score:5, Funny)

    by cascadingstylesheet (140919) on Friday February 16, 2007 @01:14PM (#18040116)

    and cell phone-billing software could charge peak rates at off-peak hours


    Aiyeeee!!!!!!!!!!!!!
    • Re:rates? (Score:5, Insightful)

      by johnlcallaway (165670) on Friday February 16, 2007 @01:17PM (#18040180)
      And could charge off-peak rates for peak hours. The number of hours for peak and non-peak will remain the same, only the start times will change.

      Everyone wants a credit when they are over billed, but no offers to give money back if they are under billed.
      • by TubeSteak (669689)

        Everyone wants a credit when they are over billed, but no offers to give money back if they are under billed.

        Well duh.

        That's because when you're overbilled, it's their fault.
        And when you're underbilled, it's their fault.

        Wait a second...
        I see what you did there.

        /Actually, it has to do with consumer protection laws, which is why businesses have to eat their losses when they underbill & give you back money if they overbill.

        • Amazon (Score:3, Funny)

          by norminator (784674)

          /Actually, it has to do with consumer protection laws, which is why businesses have to eat their losses when they underbill & give you back money if they overbill.

          Tell that to Amazon [slashdot.org].
    • Re: (Score:3, Insightful)

      and cell phone-billing software could charge peak rates at off-peak hours

      Why always the worst case is the one presented? They are equally likely to charge you off-peak rates during peak periods.

      • Re:rates? (Score:4, Insightful)

        by Qzukk (229616) on Friday February 16, 2007 @01:33PM (#18040490) Journal
        Except that peak and off-peak mean something, namely volume of calls. So as a matter of fact, no, they are not "equally likely to charge you off-peak rates during peak periods" because you're more likely to be making a peak period call than an off-peak call.
      • by Carbonite (183181)
        They are equally likely to charge you off-peak rates during peak periods.

        Maybe. This bug would cause some evening off-peak calls to be treated as peak calls (a 9:01 PM off-peak call is treated as an 8:01 PM peak call). On the other end, it would also cause some morning peak calls to be treated as off-peak calls (an 8:59 AM peak call is treated as an 7:59 AM off-peak call). I'd bet that more people are making evening calls than morning calls.
  • it is a real concern (Score:2, Informative)

    by HP-UX'er (211124)
    besides the point the OS should all run UTC, most do not. Then all the Java apps with each having its own bin/java. requires some real testing on multi-tiered client server applications, that a lot of manufacturing centers rely on.
    • by Nerdfest (867930)
      I've been on major rants for years with various people about having _everything_ maintained in UTC, using time zone localization only as a 'view' onto dates and times. The problem is, most people seem to think their own time zone is the center of the universe and don 't even realize that provblems occur even within one's own TZ because of DST variations.

      Sadly, I think those of us that are of this opinion will be once more proven correct, but will be ignored after the immediate problems have been resolved.

  • by 8127972 (73495) on Friday February 16, 2007 @01:15PM (#18040142)
    ... On how to deal with this is below:

    http://www.reganfamily.ca/dst/ [reganfamily.ca]

    This is likely more useful than the original article. It has resources for everything from Blackberries to UNIX.
  • Not such a big deal (Score:3, Interesting)

    by ThePolkapunk (826529) on Friday February 16, 2007 @01:15PM (#18040144) Homepage
    Is it a problem? Yes, but it's nowhere near as big an issue as Y2K was. The biggest issue for my company is that many of our machines are 2000, so we had to create our own patch, since Microsoft is only patching 2000 for people who pay their extortion fees.

    The majority of our applications just go off of the OS time, so as long as the OS is patched, everything else is fine. The DBA's will be coming in over a weekend to test the patches on the Unix servers, and the Server guys will be doing the same for the Windows servers, but other than that, there's not that much we have to do.

    The financial industry will probably have more problems than most, but still, it should be negligable compared to Y2K.
    • Im running into a similar problem with our 2000 machines. Willing to share that patch?
      • Re: (Score:3, Informative)

        by operagost (62405)
        Search microsoft.com for "TZedit". I used it to change the time zones, then I exported only the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones key to a .reg file. You can then push the changes out to many machines.
    • "The biggest issue for my company is that many of our machines are 2000, so we had to create our own patch, since Microsoft is only patching 2000 for people who pay their extortion fees."

      I knew it. All this smokescreen around energy savings is just a cover story.

      Naturally Microsoft is behind the change. It's all part of their master plan to move people off of legacy OS's, or bleed dry everybody else.

      How did I not see this before? Their tentacles are spreading ever further.
    • by GogglesPisano (199483) on Friday February 16, 2007 @01:38PM (#18040572)
      We have literally hundreds of servers running Windows 2000, and this DST patch was a major headache. As the parent noted, Microsoft did not include Win2K in their publicly released update.

      There is a freeware utility to apply the DST patch on Win2K machines here [intelliadmin.com] (as a bonus, it also supports WinNT).

      Note that you may also need to update the Java JRE/JDK.
    • Re: (Score:2, Flamebait)

      by Cervantes (612861)
      The biggest issue for my company is that many of our machines are 2000, so we had to create our own patch, since Microsoft is only patching 2000 for people who pay their extortion fees.

      I know exactly what you mean man! Why, just the other day, I took my 2000 Dodge Ram into the dealers because they changed the rules where I live regarding ground clearance, and the fuckers expected me to PAY for them to fix it!?! What's up with that crap? I mean, the truck is only 7 years old, they should TOTALLY still be doi
      • Re: (Score:3, Insightful)

        The company in this case isn't being asked to physically fix every installation. People just want them to make a patch available. The guys at the dealership would be more like a tech who's paid to go around and apply the patch.
  • Ahem, Not Exactly (Score:5, Informative)

    by Nom du Keyboard (633989) on Friday February 16, 2007 @01:16PM (#18040164)
    While companies like Microsoft have already patched their software,

    Ahem, not exactly. No patch for the perfectly good Exchange 5.5 server we're using with Outlook 2000. Suddenly we have to update to the latest Exchange and Outlook 2003 on every d@mn desktop. And I'm in Arizona were we don't even have daylight savings time!!!

    • Re: (Score:3, Informative)

      by FormulaTroll (983794)
      Not true. For Outlook 2000, patch the underlying OS and things will be just fine. The same applies to Exchange 5.5, patch the OS and you'll be fine as far as basic Exchange services go. It's Exchange 5.5 CDO applications, like OWA, that don't have a publicly available patch. The worst case scenerio for most people is your appointments show up an hour late during the extended DST period, and Microsoft has released tools to fix the appointments themselves - and the tool works on Exchange 5.5. An upgrade is ce
    • Um. that's what MS does. Why you should use software with better licenses.
    • Re: (Score:3, Funny)

      by Nimey (114278)

      the perfectly good Exchange 5.5 server


      Bite your tongue!
  • Cool (Score:5, Funny)

    by Anon-Admin (443764) on Friday February 16, 2007 @01:16PM (#18040168) Homepage Journal
    And I thought that the year 1906 would pass with out any issues.
  • Doomsaying? (Score:4, Insightful)

    by eln (21727) on Friday February 16, 2007 @01:17PM (#18040184) Homepage
    I don't see anyone saying planes are going to fall out of the sky or anything like that. Trades could be executed at the wrong time, costing people money. Cell phones could charge peak rates at the wrong times, costing people money. These could very easily happen if these companies were not on the ball about getting this patched early. Luckily, most operating systems required a simple patch (sometimes a reboot) to fix this, and that's about it. The extensive code fixes that the Y2K bug required simply aren't necessary here.

    However, because of the perceived simplicity of the fix, there is a real possibility that some companies waited too late to address the issue and may not make it in time. This may cause minor glitches, but it's not like the nukes are going to start flying.

    As for Y2K, obviously the people who were stockpiling ammunition and moving to the mountains were nuts, but there were real problems that could have occurred that did not because of the countless hours that were put in to fix the issues. It drives me crazy that after we spent millions of dollars and countless man hours fixing buggy code for Y2K, people look back and see that nothing happened and think all that money was a waste. If all that effort had not been expended, more computer systems would have had problems, and so the money was definitely not wasted. During Y2K, there were scattered reports of various computer systems crashing. It is likely there would have been many more such reports had we not taken the steps we did to address the issue.
  • I have a program that updates our Australia plant with new design files, some of which are modified within the hour of the last revision. The program uses a GMT timestamp for each file, and it will never overwrite an newer file with the older one. To get the timestamp, the program uses the Windows API. If Windows doesn't handle the switch, I'm going to have a lot of urgent work on my hands. So in answer to your question, yes not dealing with DST changes could cause lots of trouble! No, the issue will n
  • The DST seems pretty comparable to the Y2K thing. There are some very real risks, but they are all fixable. Some are just nuisances like reports showing the wrong time. Other are significant like messing up work schedules for crews or causing batch jobs to happen at the wrong time.

    I work at a very large company, and we're seeing a level of effort almost as big as the Y2K remediation, only on a much shorter timeline.

    This is a typical government screwup:
    1) create a solution to a problem that doesn't exist
    2
  • Bermuda? (Score:3, Insightful)

    by wiredlogic (135348) on Friday February 16, 2007 @01:21PM (#18040264)
    I don't see why Bermuda bothers with DLST. They are close enough to the equator and isolated enough that staying on normal time year round shouldn't interfere with commerce in any significant way.
  • by michaelmalak (91262) <michael@michaelmalak.com> on Friday February 16, 2007 @01:22PM (#18040280) Homepage
    Newer JDK's already have the new time zone rules encoded, and this can cause subtle bugs to suddenly surface. It turns out that Date.equals() does a deep object compare, including the time zone rules (not just which time zone you're in, but the rules regarding when daylight savings starts and ends). Thus if you have multiple JVMs involved, such as one on a database server and one on an application server running slightly different JVM revs (e.g. 1.4.2_08 vs. 1.4.2_11), then naive date comparisons (using equals() instead of equality on getTime()) can fail.
    • Which raises the question: WTF don't JVMs get their timezone info from the OS? What were the developers thinking?

      In general, I don't understand how people let this become a problem. The DST dates have already changed a couple of times within my lifetime, so I would never hard-code such a thing. This upcoming change has been scheduled for almost two years now, so every OS should have had this update in place long ago. Every app should be querying the OS for timezone info instead of hard coding it. How can

  • by Viol8 (599362) on Friday February 16, 2007 @01:22PM (#18040286)
    It serves no useful purpose any longer in what is almost a 24 hour society. What difference does it make to the vast majority of people what time the sun rises and sets anymore? All it does is add a small extra layer of confusion and complexity thats no longer necessary? If people really don't want to get up when its dark then go to work an hour later and leave an hour later. With flexitime its really not an issue anymore.
    • Thing is nobody wants to start work at 7 in the morning, so the government went out and renamed 7 as 8 for most of the year, and idiots think they're getting "more daylight" rather than getting up an hour earlier. Personally I'd rather everyone go on Greenwich Mean Time so I could start work at 13:00 and get off at 21:30, but apparently that's too confusing for some people.
    • by Dachannien (617929) on Friday February 16, 2007 @02:29PM (#18041616)
      Let's switch to the metric system while we're at it.

  • Hey, there might be some other great task involved in banking or travel programs but in the end, i don't think its gonna do anything.

    If i was paranoid i'd probably say this is a scheme to create jobs and make money.

    I've been programming for 10 years now and programs don't generate their own time. well, I never created my own clock anyway, i don't see any need for it.

    Whatever daylight saving changes do they are applied to the system clock and programs uses system clock. why would it matter when the OS decide
    • "The only instance where i can see this causing a problem is when programs monitors the time on a particular day, say the day where daylight is supposed to kick in/out"

      It shouldn't. You are right about no application having to deal with current time. They only ask the underlying OS "What time is it? and the OS answers "It's XX:YY UTC now"; that's all. And, ho and behold, the UTC second that follows the second prior to a daylight saving change is still one UTC second later, no time drift at all.

      Except, of
  • The solution is in /usr/share/zoneinfo/right/
  • by poopie (35416) on Friday February 16, 2007 @01:32PM (#18040462) Journal
    Think of how many companies have old systems that just continue to run forever. Most OS vendors drop OS patch support after about 5 years.

    Okay, so all system processes should use UTC. We all know that. Users don't set their watches to UTC though.

    Want a DST patch for Solaris 8? RHAS 2.1? Windows NT? You're going to have to shuffle and maybe you'll need to update the timezone files with 'zic' yourself. Have hundreds or thousands of these machines. Sucks to be you.

    Oh, and the big killer is that Java has timezone rules embedded in it. That's right. Java VIRTUAL MACHINE. Java tracks timezones and DST changes INDEPENDENT of the OS since Java wants to be it's own OS.

    So, if your company standardized on j2ee when you moved off the legacy systems for y2k, I'll almost bet you that the OS those java apps are running on won't have DST patches from the vendor, and your apps could have multiple JVMs that contain the wrong DST rules. You'll need to fix both of those if your java apps have anything to do with timezones and if you care about the times displayed.

    I'd really like to get a list of everyone who voted for the 2005 dst timezone changes and start a movement to make them take responsibility for the huge business cost of their stupid legislation. It has to be 100X the cost of what they expected the changes to save...
  • by Whiteout (828544) on Friday February 16, 2007 @01:32PM (#18040464)
    The tz database http://www.twinsun.com/tz/tz-link.htm [twinsun.com] underlies time zone handling for the GNU C Library, FreeBSD, NetBSD, OpenBSD, Mac OS X, Solaris and many more, and is kept current by a dedicated team of (mostly?) volunteers. For time nerds, the historical comments in the plain text files of the tz ftp distribution (ftp://elsie.nci.nih.gov/pub/tzdata2007b.tar.gz [nih.gov]) are required reading.

    If you're a Firefox person, FoxClocks (see my URL above) puts nice little world clocks on your statusbar. And yes, it uses tz too. Thanks guys. Andy
  • Joanna: So, where do you work, Peter? Peter: Initech. Joanna: In... yeah, what do you do there? Peter: I sit in a cubicle and I update bank software for the Daylight Savings Time switch.
  • by wsanders (114993) on Friday February 16, 2007 @01:36PM (#18040534) Homepage
    This is worse than Y2K because Java needs to be patched, and JVMs proliferate on hosts like cockroaches. Older JVMs cannot be patched.

    There are nearly 50 java instances on some of our hosts. The filthy little bastards hide everywhere.

    Fortunately the fix can be automated and is very fast to install.

    Using java's extensive built-in patch management and version management capabilities, of course.
  • I always thought that operating systems and time-critical systems should always use Universal Time internally. It's fine to display stuff to the user in local time, but all the innards should be UTC. I loved my first Debian install when it told me how my computer clock was going to stay on UTC, and the display time would be acoording to whatever time zone I chose. Then I wondered why the heck Windows actually went and changed the hardware clock. That seems so stupid in retrospect. I'm sure some stuff w
  • Assuming you set all your servers off of a local time server which is set off of an official time server, is this much of an issue?

    • NTP uses UTC (Score:3, Informative)

      by wsanders (114993)
      NTP doesn't know diddly about your timezone. Otherwise, how would you be able to conenct to a NTP host in another TZ?

      So you need to patch unless you don't care about your clocks being off. Or you're in an area unaffected by recent changes.

  • that nobody's even considering the possibility that cell phone companies could charge off-peak fees during peak hours. That just doesn't happen.
  • NTP for Everyone (Score:3, Interesting)

    by Doc Ruby (173196) on Friday February 16, 2007 @01:40PM (#18040614) Homepage Journal
    The NTP server system is very reliable. Its servers should also include software upgrades that clients can fetch, with an authorization system in the clients. The US NIST should produce reference standard software that the NTP servers can offer, digitally signed by NIST, and test/certify/sign 3rd party SW. And the Congress should require the insurance industry to adopt uniform standards for liability when companies don't upgrade to the industry operations standard.

    This function is too important to leave to corporations that have demonstrated they upgrade themselves in their own interest only when it's a years-long campaign that everyone talks about. So it's time to automate the process. Otherwise, Americans and others in the global economy will pay much higher costs in damage and loss later, cleaning up the mess.
  • Just like Dec 31, 1999!
  • by thewiz (24994) * on Friday February 16, 2007 @01:43PM (#18040650)
    You'll catch up to the rest of us in three weeks!
  • I'm used to running and writing systems that use UTC for everything, including the user interface, because the systems may be installed anywhere in the world. How do you deal with "local time" in networked systems where the users insist on using local time? Even a small network may cross time zones. What about clock synchronization in Windows-based networks? Does it convert everything to UTC? This sounds like it could be a mess for companies that insist on presenting the user with local time in networked ap
  • Apple (Score:3, Informative)

    by metroplex (883298) on Friday February 16, 2007 @01:45PM (#18040692) Homepage
    Apple just pushed an update through Software Update that fixes potential daylight saving time problems. You can grab it here [apple.com] if you use Tiger, or here [apple.com] if you still use Panther. It also released a similar update for Java. here [apple.com] is the Tiger version and here [apple.com] is the Panther one.
  • Daylight Savings is truly a software development nightmare. I used to work on a product that had to read in data in clock time (i.e. like on your wristwatch) and convert into local time (always continuous with no clock changes). The system read in data in hourly chunks and had to work in the UK, Europe and elsewhere. It doesn't matter how clever people are, clock changes are always confusing. We'd be testing the system and always having disagreements over whether it was working correctly. Customers would al
  • by circletimessquare (444983) <circletimessquare&gmail,com> on Friday February 16, 2007 @01:48PM (#18040770) Homepage Journal
    i recognize the interest in giving people more daylight hours for harvest/ farming purposes... and how that's still nice in a service/ industrial work setting to have barbeque time after work

    but why does that mean that time has to be shifted twice every year? why not just shift time by an hour once, just one time, and be done with the nonsense forever? why is it necessary to go back to "real" time in the winter?

    heck, sometimes i think we should redefine 6 am as 3 am. then everyone wakes up and goes to work in the middle of the "night", and, after work in the summer, you have daylight until midnight!

    we're dealing with an abstract concept here. we can do whatever we want with time. we don't have to abide by some weird need to swithc back to "real" time in the winter. just shift it once in favor of farmers/ after work barbequers and be gone with it. it's just so stupid and pointless and a waste of effort to constantly shift back and forth
    • When I'm benevolent fascist dictator everyone will go by Greenwich Mean Time (aka Zulu time aka Coordinated Universal Time [wikipedia.org]). Yeah sure everyone will be all pissed off at first when they have to go to bed at 7:00 in Tokoyo or wake up at 23:00 in Los Angeles, but they'll get used to it. And it will be hard for people to change, but that's why I need to be appointed to the head of the U.N.'s Dictatorial Standards Department.

      Remember you'll never have to reset your wrist watch again. NEVER. And when gets a
    • Re: (Score:3, Informative)

      by ElleyKitten (715519)

      but why does that mean that time has to be shifted twice every year? why not just shift time by an hour once, just one time, and be done with the nonsense forever? why is it necessary to go back to "real" time in the winter?
      Because then the little kids would have to stand in the dark to wait for their buses. Which they do anyways if they live north enough. You're right, it is stupid.
  • by OrangeTide (124937) on Friday February 16, 2007 @02:23PM (#18041496) Homepage Journal
    % zdump -v /etc/localtime| grep 2007 /etc/localtime Sun Mar 11 09:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 PST isdst=0 gmtoff=-28800 /etc/localtime Sun Mar 11 10:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 PDT isdst=1 gmtoff=-25200 /etc/localtime Sun Nov 4 08:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 PDT isdst=1 gmtoff=-25200 /etc/localtime Sun Nov 4 09:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 PST isdst=0 gmtoff=-28800

    notice that the isdst changes from 0 to 1 on March 11. This means I have the correct zoneinfo file in my system. /etc/localtime is a symbolic link to the default timezone for your machine. (users can run their own timezone with the TZ environment variable).

    % ls -l /etc/localtime
    lrwxrwxrwx 1 root root 30 2006-09-24 21:50 /etc/localtime -> /usr/share/zoneinfo/US/Pacific

    PS - likely the steps to check this on FreeBSD are similar. Post your experiences.
  • by Tired and Emotional (750842) on Friday February 16, 2007 @02:35PM (#18041710)
    IT at my company told us several weeks ago NOT to take the Microsoft patch as they were working on their own. They rolled it out to us this last week.

    It was a complete disaster. Now my calendar entries for the affected week are mostly off by an hour (not all of them mind you) while a friend who displays dual timezones now has one less timezone in the continental US - the west coast is only two hours behind the east coast. Probably he can fix this by turning it off and back on, but it looks like we will have to rebook all meetings.

    Of course, one can certainly argue that correctly implemented software would not have a problem since everything would be done internally in UTC, but clearly not all software is correctly implemented.

    As for the stupid change - if they had brought us into line with Europe there would have been some logic to the change. This one was just make work for a cheap political stunt.

  • by dokebi (624663) on Friday February 16, 2007 @02:52PM (#18041990)
    Why does Windows not run UTC on the CMOS clock? Doing so would solve all of this "The computer has changed the clock" twice a year. The clock wouldn't be changed, just synced every now and then, but the displayed time would automatically be adjusted. POSIX and MacOS does this correctly, and 99.99% of Mac users don't even realize their CMOS clock runs UTC. Changing Daylight Time would be updating a single file, even in a closed OS like windows.

    I've heard all sorts of dumb reasons against running UTC on the CMOS, like "who cares about UTC, My time is local" and "why should I keep two different times on my computer".
    But, the OS will hide the UTC from you, and besides, when was the last time you used the BIOS time as your clock?

    Forcing UTC on the CMOS clock is surprising since WindowsNT has used UTC for all their internal time tracking for some time. But they *calculate* it from local time, which changes twice a year, _even though_ Windows uses NTP time servers. Doh. It's gotta be *the* dumbest backward compatibility "feature". See here: http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html [cam.ac.uk]
  • by sallgeud (12337) on Friday February 16, 2007 @03:29PM (#18042582)

    It's "Daylight Saving Time" NOT Savings...

    http://en.wikipedia.org/wiki/Daylight_saving_time# name [wikipedia.org]
  • by Se7enLC (714730) on Friday February 16, 2007 @03:50PM (#18042858) Homepage Journal

    > date --date="Mar 10 15:00:00 UTC 2007"
    Sat Mar 10 10:00:00 EST 2007
    > date --date="Mar 11 15:00:00 UTC 2007"
    Sun Mar 11 11:00:00 EDT 2007

    This won't set your clock or anything, it just does the timezone conversion from UTC and displays the results according to the local timezone you have selected.
    • by srvivn21 (410280) on Friday February 16, 2007 @04:47PM (#18043850)


      > date --date="Mar 10 15:00:00 UTC 2007"
      Sat Mar 10 10:00:00 EST 2007
      > date --date="Mar 11 15:00:00 UTC 2007"
      Sun Mar 11 11:00:00 EDT 2007

      This won't set your clock or anything, it just does the timezone conversion from UTC and displays the results according to the local timezone you have selected.
      Or just run zdump -v /etc/localtime | grep 2007" and make sure it says "Mar 11" instead of "Apr 1".

      updated> zdump -v /etc/localtime | grep 2007
      /etc/localtime Sun Mar 11 10:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 AKST isdst=0 gmtoff=-32400
      /etc/localtime Sun Mar 11 11:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 AKDT isdst=1 gmtoff=-28800
      /etc/localtime Sun Nov 4 09:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 AKDT isdst=1 gmtoff=-28800
      /etc/localtime Sun Nov 4 10:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 AKST isdst=0 gmtoff=-32400

      needswork> zdump -v /etc/localtime | grep 2007
      /etc/localtime Sun Apr 1 10:59:59 2007 UTC = Sun Apr 1 01:59:59 2007 AKST isdst=0 gmtoff=-32400
      /etc/localtime Sun Apr 1 11:00:00 2007 UTC = Sun Apr 1 03:00:00 2007 AKDT isdst=1 gmtoff=-28800
      /etc/localtime Sun Oct 28 09:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 AKDT isdst=1 gmtoff=-28800
      /etc/localtime Sun Oct 28 10:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 AKST isdst=0 gmtoff=-32400

We can predict everything, except the future.

Working...