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!!!!!!!!!!!!!
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.
... 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.
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.
Dear diary: Today I stuffed some dolls full of dead rats I put in the blender.
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.
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.
Or you could put configuration data like say, time zone rules, into an external file so they could be easily updated without recompiling the kernel or rebooting. Yeah, I vote for that plan.
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.
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.
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...
The tz database http://www.twinsun.com/tz/tz-link.htm 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) 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
http://support.microsoft.com/gp/dst_topissues#a5
You're exactly right, except for the parts where you're talking out of your ass. There are automatic updates for XP and 2000, and instructions for updating Nt4 manually. Vista does in fact ship with the updated DST rules.
Oh Lords of Cobol, hear our prayers... So say we all.
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.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
Our Solaris servers need patching for the changes, and will need rebooting afterwards; our Windows servers need a line in the reg changing and no reboot.
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.
--
make install -not war
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"?
Solaris is a mess - they put timezone data for timezone names like "US/Pacific" etc in zoneinfo tables but "POSIX" timezones like PST8PDT etc have the rules hardwired into libc.so. So a libc.so patch is required, which also patches various other .so's, PAM config files, a smallish number of prerequisite patches, and of course a system reboot. Making the Solaris patch a non-trivial exercise unlike Linux and Java.
As Dr Phil would say "what WERE you thinking"?
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
Apple just pushed an update through Software Update that fixes potential daylight saving time problems. You can grab it here if you use Tiger, or here if you still use Panther. It also released a similar update for Java. here is the Tiger version and here is the Panther one.
"Words of wisdom: drop that zero and get with the hero" -- Vanilla Ice
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
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
Where's the "automatic update" for Windows 2000?
From the URL you directed us to:
So it sounds like they have a fix, but I need to pay to get it?!
Everything is fine in Australia? Remember folks, this announcement is coming from the country that gave us The Wiggles.
"daylight savings times and zones change constantly in australia and everything is fine here, no need to worry"
I take it that you don't work for a "The sky is going to fall unless you get 500 copies of our Timezone Prevention Software" Vendor?
There are no loopholes. It's either legal or it's not.
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.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
When I'm benevolent fascist dictator everyone will go by Greenwich Mean Time (aka Zulu time aka Coordinated Universal Time). 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 assassinated by in at 11:34 you will know exactly where you were at that exact moment. No calculations needed.
And then after that I'll get everyone to switch to metric.
Tell that to Amazon.
The Wiggles had a personnel change recently and every computer in the country had to be patched!
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
% 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
/etc/localtime is a symbolic link to the default timezone for your machine. (users can run their own timezone with the TZ environment variable).
/etc/localtime /etc/localtime -> /usr/share/zoneinfo/US/Pacific
notice that the isdst changes from 0 to 1 on March 11. This means I have the correct zoneinfo file in my system.
% ls -l
lrwxrwxrwx 1 root root 30 2006-09-24 21:50
PS - likely the steps to check this on FreeBSD are similar. Post your experiences.
“Common sense is not so common.” — Voltaire
Let's switch to the metric system while we're at it.
I work for a large bank; we have had very aggressive efforts to get everything patched in time and have spent thousands of man-hours getting this done. Bear in mind that all of this becomes ever-more difficult when you have to schedule the patching, follow change control process, etc... even if it doesn't require an outage. Some of the items that are involved that I haven't seen much discussion on: - Solaris - AIX - HP-UX - Java - Oracle All of these need patched; java is particularly troublesome because there are so many instances it spewed everywhere.
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.
Squirrel!
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 dates, not only does the customer see the wrong time on the bill, and say "I didn't call anyone at 7pm!", but they got may have been billed for it at the wrong rate.
Calendar appointments in your PIM could all be shifted an hour (or not shifted an hour) and you'd miss your doctors appointment. Java contains a copy of the offset tables as well, so admins need to make sure they've got the Java TZ Updater rolling to every copy of the JRE in every Java-based program on every computer in their organization (plus the actual standard JRE install).
My point is that this isn't a nothing problem, and a lot of administrators, programmers, companies, and universities have to scramble to get everything fixed correctly.
XeoMage
"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
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*!
How to build the Unix Zoneinfo Time Zone Files Manually
Build binary zone files:
1: download the latest copy of ftp://elsie.nci.nih.gov/pub/tzdata*.tar.gz. This will include the details of the DST change. You could also update the source files by hand i.e.: /usr/share/lib/zoneinfo/src in solaris
2: view file to ensure necessary changes have been made.
3: compile the binary zone file per the instructions of the time zone compiler 'zic' which comes with the system.
4: install the new binary zone file over the current zone file, making sure all symbolic links, etc, are updated as needed.
It's "Daylight Saving Time" NOT Savings...
http://en.wikipedia.org/wiki/Daylight_saving_time
> 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.
My system is displaying local time, and every way I know of to get a timestamp in several coding environments will give me UTC, though some will ask the operating system to convert to local if I want them to. Which it handles just great.
Windows is stupid in a whole lot of ways. But it is not utterly lacking in basic requirements like time handling.