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?
http://www.bloomingtonlinux.org/wiki/DST_Time_Chan ge_Issues
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.
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 cell phone-billing software could charge peak rates at off-peak hours
Aiyeeee!!!!!!!!!!!!!
... On how to deal with this is below:
http://www.reganfamily.ca/dst/
This is likely more useful than the original article. It has resources for everything from Blackberries to UNIX.
This is my opinion. To make sure you don't steal it, it's covered by the DMCA.
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!!!
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
And I thought that the year 1906 would pass with out any issues.
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.
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.
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...
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 (as a bonus, it also supports WinNT).
Note that you may also need to update the Java JRE/JDK.
Everything is fine in Australia? Remember folks, this announcement is coming from the country that gave us The Wiggles.
Let's switch to the metric system while we're at it.
"In no way were dates routinely stored as two byte characters (99 being the max) when 1 byte would get you to 255 easily." Wrong. In EVERY WAY dates were routinely stored as three sets of two byte characters.
What you are completely ignoring is that the vast majority of the code that had to be examined and patched was written in COBOL. COBOL that store dates as a string of six digits. Digits that were stored in many cases as EBCDIC characters, not hexadecimal integer values. And just to make it fun, in some cases the source code was not available.
"[A]nyone that created a four digit date by String Concat: "19" + String(date) would " probably not have been born yet when the programs that needed to be fixed were written. It wasn't the programs that were written in the 1990's that had to be dealt with, it was the ones written in the 1960's. And if you don't believe there were any of those in use, then I suggest you have no idea what's really happening at your bank. Or in the US air traffic control system, for that matter.
Slightly disreputable, albeit gregarious
> 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.