'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

Things you should know.

[suso]

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.

Re:Things you should know.

[jcgam69]

We're already having serious problems with this change. Patched windows workstations show different appointment times than unpatched workstations. We're planning to roll out the windows patch, http://support.microsoft.com/kb/928388, to all computers ASAP.

Re:Things you should know.

[VertigoAce]

The thing that I've seen warnings about is people trying to schedule meetings/events/etc that happen during the time between the new and old time changes. Generally you schedule something with respect to local time, but the program itself stores it as UTC (as you suggest). If you scheduled it on an unpatched machine, it would be an hour off when you got around to patching the machine.

Re:Things you should know.

[Anonymous Coward]

Windows CANNOT use UTC and display local time. It is the only operating system that REQUIRES that the system clock and the hardware clock be set to the same time.

Re:Things you should know.

[danielblair]

Amen!

Seagate and Peregrine/HP have some really nice, robust, Data Center Management software for managing 10s, 100s, or even thousands of computers and the software on them... you can push, say, SP2 to all 5000 machines, and it's like a few clicks to do it.. and it takes care of everything! Then you check the error report, etc. to make sure that none of the known machines encountered an error (or were turned off at the time), and then you address them individually...

With the # of servers that you are talking about, I wouldn't even think of doing it manually.. unless you get paid by the hour and literately have nothing else to do for the next few months (or year - as per your statement about almost being done after having started the update(s) a number of months back..) It would be well worth your investment to install something like this so that you could push a patch, or a simple update (like windows malicious software removal tool monthly update, etc.) to selected machines, or all machines, and do it from a single console..

To each his own though..

Re:Things you should know.

[Christopher_G_Lewis]

Add 8-10 JRE's per server, versions 1.3.x through 1.5.x and a different JRE updater for each vendor, the upcoming MSVCRT.DLL updates and it quickly becomes a huge world of hurt.

The Sun JRE updater has to be run on each installed version of the JRE. Remove the old ones? Not a chance - could break an app. What about 1.3, well, you're SOL.

IBM thought they were brilliant with their 1.4 & 1.5 implimentation - They roll the ZI info into the Core.JAR file. No one will monkey with it there. Their updater unpacks the CORE.Jar file, updates the ZI table, then zips it back up and copies it to the JRE directory. Unless the JRE is running, in which case the jar file is locked and can't be over written. Copy it to the JRE directory, mark it for replacement? No chance, you have to unload the JRE and run the tool again.

Where's the IBM JRE? MQ Series, IBM Director for our blades, Tivoli. So I need to log on to each box, stop tivoli, MQ Series and the director agent, run the IBM patch tool (which is a POS, since you have to run it *twice*, once to "discover" the JRE's and versions, once to fix them) then reboot the box.

Next week MS is releasing the CRT library patches, since they fubar the _tzset() Posix call. And oh yes, that's a server reboot there also.

What a PITA.

I've definitely lost more of my hair this month then ever before.

Makes me *really* want to leave IT.

Re:Things you should know.

[Zen]

I work in network support, so our changes are relatively easy.

However, I heard from one of the Unix guys (solaris, linux, AIX, HP-UX, younameit) that after getting halfway through patching the systems, which apparently requires a reboot, IBM told them that Java also requires a patch which also requires (or recommends) a reboot. So they had to start all over again because nobody thought to check Java before they started. If you support systems that use Java and hadn't heard about that yet, you will definitely want to look into it.

it is a real concern

[HP-UX'er]

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.

A site that will give you USEFUL Info.....

[8127972]

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

There is no time bank

[Anonymous Coward]

It's daylight saving time, not daylight savings time. There is no bank. Or spoon.

Ahem, Not Exactly

[Nom du Keyboard]

While companies like Microsoft have already patched their software,

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!!!

Re:Ahem, Not Exactly

[FormulaTroll]

Not true. For Outlook 2000, patch the underlying OS and things will be just fine. The same applies to Exchange 5.5, patch the OS and you'll be fine as far as basic Exchange services go. It's Exchange 5.5 CDO applications, like OWA, that don't have a publicly available patch. The worst case scenerio for most people is your appointments show up an hour late during the extended DST period, and Microsoft has released tools to fix the appointments themselves - and the tool works on Exchange 5.5. An upgrade is certainly not a requirement.

Re:Ahem, Not Exactly

[FormulaTroll]

My company runs Exchange 5.5 and a mix of Outlook 98 through 2003 on the clients. Here's the supporting data for my claims in the previous message:

This article says Outlook 2000 is fine as long as the OS is patched: http://support.microsoft.com/gp/dst_topissues

This article discusses how CDO is the only reason Exchange needs to be patched: http://support.microsoft.com/kb/926666

The Outlook appointment tool is here: http://support.microsoft.com/kb/931667

The Exchange server version is here: http://support.microsoft.com/kb/930879

A round of applause for the tz guys

[Whiteout]

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

Re:Linux?

[n0dna]

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.

saving, not savingS

[r.binky]

We are only saving one thing, daylight. There is no plural on saving. Daylight Saving Time.

Re:Not such a big deal

[GogglesPisano]

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.

yes, there is a bug

[kayditty]

It is Daylight Saving Time, and not Daylight "Savings" Time.

Don't laugh

[wsanders]

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

Apple

[metroplex]

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.

Re:Linux?

[VWJedi]

Where's the "automatic update" for Windows 2000?

From the URL you directed us to:

Windows 2000 has passed the end of Mainstream Support and will not be receiving an update without Extended Hotfix Support.

So it sounds like they have a fix, but I need to pay to get it?!

Re:Not such a big deal

[operagost]

Search microsoft.com for "TZedit". I used it to change the time zones, then I exported only the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones key to a .reg file. You can then push the changes out to many machines.

Re:y2k = media working for once

[DrXym]

I think y2k was a let down because it was fairly straightforward to fix software and tell if it was going to get bitten or not. Basically anything that stored dates as two digits had to be fixed. The bigger problem will come in 2037 when lots of clunking software with no source code wraps around.

The DST thing is pretty evil too because it's usually up to runtime stacks like Java and CRT to decide on the timezone and time. If they give you the wrong time you're screwed. For the most part you might be okay if everything resolves down to some registry entries or timezone data files but that isn't always the case. There are functions such as Microsoft's _tzset() which are HARDCODED to a particular behaviour and apps that link to the CRT or have their own DLLs will be broken unless you recompile them.

Re:rates?

[camg188]

I work for a company that does rating and billing for cell phone companies. This will not be a problem. It's not a unique situation. For instance, in Brazil, daylight savings start and end dates are different every year (I think the date is set by a presidential decree), yet it hasn't been a problem.

NTP uses UTC

[wsanders]

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.

Re:daylight savings time is stupid

[ElleyKitten]

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?

Because then the little kids would have to stand in the dark to wait for their buses. Which they do anyways if they live north enough. You're right, it is stupid.

Re:Bermuda?

[joejor]

Bermuda serves as a banking and tax haven for many corporations and individuals. It would be a shame if a big sum of money were to vanish into the ether because a Bermudan computer refused to accept a wire transfer from "the future."

You are totally without a clue

[Anonymous Coward]

This completely ignores a VITAL fact... computers are binary, NOT decimal. The number 100 is significant and moves to 3 digits in decimal space, but is UNINTERESTING in binary


There were (are) a TON of systems that store dates, not as a number, but as 2 characters. You young whippersnappers may think everything works the way you learned in school, but mainframes still run the world.

Verify your Linux box is correct.

[OrangeTide]

% 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

notice that the isdst changes from 0 to 1 on March 11. This means I have the correct zoneinfo file in my system. /etc/localtime is a symbolic link to the default timezone for your machine. (users can run their own timezone with the TZ environment variable).

% ls -l /etc/localtime
lrwxrwxrwx 1 root root 30 2006-09-24 21:50 /etc/localtime -> /usr/share/zoneinfo/US/Pacific

PS - likely the steps to check this on FreeBSD are similar. Post your experiences.

Re:Bermuda?

[LMacG]

Close enough to the equator? Better spin that globe one more time:

"Bermuda is farther north than Caribbean destinations. Located in the Atlantic, Bermuda's latitude is equal to that of North Carolina. "

Re:Solaris will be a problem?

[Em Adespoton]

From http://www.reganfamily.ca/dst/ :
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.

I hate to be the first to point out...

[sallgeud]

It's "Daylight Saving Time" NOT Savings...

http://en.wikipedia.org/wiki/Daylight_saving_time# name

How to test if your linux machine is ready

[Se7enLC]

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

Re:How to test if your linux machine is ready

[srvivn21]

> 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. Or just run zdump -v /etc/localtime | grep 2007" and make sure it says "Mar 11" instead of "Apr 1".

updated> zdump -v /etc/localtime | grep 2007
/etc/localtime Sun Mar 11 10:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 AKST isdst=0 gmtoff=-32400
/etc/localtime Sun Mar 11 11:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 AKDT isdst=1 gmtoff=-28800
/etc/localtime Sun Nov 4 09:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 AKDT isdst=1 gmtoff=-28800
/etc/localtime Sun Nov 4 10:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 AKST isdst=0 gmtoff=-32400

needswork> zdump -v /etc/localtime | grep 2007
/etc/localtime Sun Apr 1 10:59:59 2007 UTC = Sun Apr 1 01:59:59 2007 AKST isdst=0 gmtoff=-32400
/etc/localtime Sun Apr 1 11:00:00 2007 UTC = Sun Apr 1 03:00:00 2007 AKDT isdst=1 gmtoff=-28800
/etc/localtime Sun Oct 28 09:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 AKDT isdst=1 gmtoff=-28800
/etc/localtime Sun Oct 28 10:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 AKST isdst=0 gmtoff=-32400

-1 False

[2short]

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.

Re:Mod Parent Up

[azrider]

I work very heavily with the emergency management offices for my state, county and city (Ham Radio operator, ARRL Emergency Coordinator). In 1999, the various EM groups started testing for Y2K, and found just 2 problems 1) The CAD system for 911 dispatch failed the test. 2) The system controlling card key access to the city Emergency Management Center and Police/Fire Dispatch failed the test. We were able to fix the problems prior to Y2K. The situation is the same with the DST change. 911 dispatching operations are way too critical to take a chance. In addition, they tend to be on systems that are one to two releases down, since "bleeding edge" platforms and emergency operations are mutually incompatible.