Slashdot Mirror


'Daylight Savings Bugs' Loom

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?

6 of 403 comments (clear)

  1. y2k = media working for once by TinBromide · · Score: 5, Insightful

    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.

    --
    Is it sad that I am more likely to recognize you and your posts by your sig than your name or UID?
  2. Re:rates? by johnlcallaway · · Score: 4, Insightful

    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.

    --
    I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
  3. Get rid of daylight saving altogether by Viol8 · · Score: 4, Insightful

    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.

  4. Old OSes and Old JREs are the biggest concern by poopie · · Score: 4, Insightful

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

  5. Re:Things you should know. by shawn(at)fsu · · Score: 4, Insightful

    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.

    --
    500 dollar reward for tip(s) leading to the arrest of the person(s) who stole my sig.
  6. Re:Things you should know. by tushar · · Score: 4, Insightful

    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.