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

Comments

Re:Things you should know.

[Ubergrendle]

Our datacentre has ~ 500 Solaris / HP-UX / AIX boxen, and ~ 1000 Windows servers.

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

[michaelmalak]

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.

daylight savings time is stupid

[circletimessquare]

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

Re:daylight savings time is stupid

[curunir]

FYI...This latest "fiddling" with DST is designed to figure out just how much energy DST actually saves (if any). By adjusting the date when DST goes into effect, and measuring the difference in energy consumption compared to previous years, we should get a good idea of whether DST is providing any energy savings and whether that savings is worth the trade-offs (there are quantifiable costs associated with DST...things like increased auto accident rates around the changeover dates).

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:Things you should know.

[Marillion]

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.

[pe1chl]

When you are so careful about file timestamps, you should know that Windows does not translate them correctly anyway.
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.

Re:Y2K was an oddity and mis-explained

[LMacG]

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

Re:Mod Parent Up

[Stanistani]

Where I worked, we had a lot of old but reliable systems. We tested our mainframes, minicomputers, PCs, and network systems - they failed in varying and catastrophic ways.

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.