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?
daylight savings times and zones change constantly in australia and everything is fine here, no need to worry
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?
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.
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.
Why always the worst case is the one presented? They are equally likely to charge you off-peak rates during peak periods.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
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.
I am becoming gerund, destroyer of verbs.
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.
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.
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.
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...
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.
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.
If I have been able to see further than others, it is because I bought a pair of binoculars.
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.
You'll catch up to the rest of us in three weeks!
If "disco" means "I learn" in Latin, does "discothèque" mean "I learn technology"?
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.
$signature =~ s/$signature//;
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.
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.
Or you could move to Arizona and forget about this 18th century nonsense.
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
In Soviet Russia, articles before post read *you*!
Regardless of whether the information was "hard coded" or written entirely using logic (math, variables, etc...) doesn't change the fact that the computers still need to be updated. Granted, it is probably much easier for the developer to patch a single number in thousands of lines of code rather than have to re-code it all to accommodate for the change, but you will still have to physically "patch" each computer. I personally blame my government for this, they should have wiped this "mandatory time change" with the invention of the light-bulb...