'Daylight Savings Bugs' Loom 403
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?
Not such a big deal (Score:3, Interesting)
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.
Brazil (Score:1, Interesting)
Re:Linux? (Score:3, Interesting)
Re:Things you should know. (Score:5, Interesting)
15 minute change window to apply patch, another 15 minutes to reboot successfully and come back online. Multiply 30 min x 1500 = 45,000 minutes, or 750 hours. But we only have one weekly change window, Sunday mornings from 2-6am. Assuming finite number of staff, contingency (there's always going to be some problems), etc... we started last September. We might just make the deadline.
So yes, I think its a bit of a problem. There's also the unspoken assumption that people learned their lessons during Y2k and have sufficient date handling logic to address changes to DST...nothing hard coded in the underlying applications.
Already has ramifications (Score:5, Interesting)
Re:Linux? (Score:2, Interesting)
NTP for Everyone (Score:3, Interesting)
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.
daylight savings time is stupid (Score:4, Interesting)
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
Re:Mod Parent Up (Score:3, Interesting)
Since the only people who really know about it are the people who made money out of it, it's hard to accept a claim of "we all just did our jobs and saved the world."
Re:Things you should know. (Score:4, Interesting)
Most programs that use the standard C library do use UTC and just don't realise it. The most important thing to realise about daylight savings time is that Time isn't changing. The sun still rise the after DST as before DST (astronomical adjustments due to Earth's heliocentric orbit not withstanding). But, how we read the clock is changing.
I heard one company just say, "we're going to just change the clock on the computer." This makes me cringe.
All file time timestamps on all versions of UNIX and versions of Windows derived from NT store times as Julian seconds since 1970-01-01 00:00:00 GMT. Changing the system clock means that the times will be stored wrong even though they display properly in the local timezone.
Other places to watch out for are applications that manage their own timezone data. Java is a prime example. Major database vendors would be another.
Re:Things you should know. (Score:4, Interesting)
Windows has no knowledge about timezone history. It translates the UTC time to local time using its current time-offset, which depends on the current DST status only.
So, when you now look at a file timestamp (in the GUI) that you created last summer, you will find that its time is one hour off.
Even when Microsoft would finally fix this (they consider it a feature rather than a bug), they would probably not fix the historic aspect.
I.e. now that the beginning of DST shifts one month, and you would look at a file created last year in that one month window, it would probably still be off.
Timezone handling in Windows just sucks. It does not have to be that bad, it works fine in Linux (including historic changes). Microsoft just has decided to make a bad implementation and then never fix it, in the name of backward compatability.
This -is- a big deal (Score:2, Interesting)
Its not just "unprepared" companies (Score:3, Interesting)
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.
Not that simple. (Score:3, Interesting)
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.
Re:Y2K was an oddity and mis-explained (Score:5, Interesting)
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.
Re:daylight savings time is stupid (Score:4, Interesting)
There's also some notion that in the modern world DST actually increases the country's energy consumption. DST was originally conjured up in a world where the bulk of the energy consumption came from lighting. In that world, giving people daylight at certain hours of the day reduced their need for artificial light. In our modern world, however, things aren't that simple. For one, we have lighting that uses less energy than before. But the biggest difference is that we now have air conditioners, something that uses significantly more energy than our modern lighting. In the modern world, by ensuring that there is natural light when people get home from work, we increase the likelyhood that they will need to use their air conditioners.
So, we really have no idea whether DST actually serves its purpose anymore or if it's merely an unecessary inconvenience for any modernized country. This year's change in the time that DST goes into effect will give us a good indication of whether we can eliminate DST entirely.
Re:Mod Parent Up (Score:4, Interesting)
We spent millions of dollars for all new systems, and thousands of hours in planning, procurement, implementation, and testing. We literally pushed all the boxes on the datacenter floor to the wall and built anew.
It was a horrendous chore, and I didn't get to spend New Year's with my family.
Perhaps we should have let you all freeze in the dark.