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

no need o worry

[Anonymous Coward]

daylight savings times and zones change constantly in australia and everything is fine here, no need to worry

y2k = media working for once

[TinBromide]

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.

Re:rates?

[johnlcallaway]

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.

Doomsaying?

[eln]

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.

Re:rates?

[Nom du Keyboard]

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.

Bermuda?

[wiredlogic]

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.

Get rid of daylight saving altogether

[Viol8]

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.

Mod Parent Up

[ObiWanStevobi]

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.

Mod Freakin' Parent Up

[Nerdfest]

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.

Old OSes and Old JREs are the biggest concern

[poopie]

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

Re:Things you should know.

[shawn(at)fsu]

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:rates?

[Qzukk]

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.

Re:Things you should know.

[vadim_t]

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.

No big deal if you don't update...

[thewiz]

You'll catch up to the rest of us in three weeks!

Re:Things you should know.

[Poruchik]

It is not enough. For example:
Your user schedules a meeting for 9am EST, March 26th. Your (unpatched) system duly converts it to 14:00 GMT. Later, after the patch to local box, user comes in and sees that his meeting was mysteriously rescheduled to 8am.
What happened?
Due to the new DST, GMT (or UTC) is 4 hours off instead 5 that it used to be.

Re:Things you should know.

[gclef]

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.

Re:Not such a big deal

[Pantero Blanco]

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.

Re:Things you should know.

[sp3d2orbit]

Or you could move to Arizona and forget about this 18th century nonsense.

Windows and CMOS clock

[dokebi]

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]

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Things you should know.

[tushar]

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.