Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

'Daylight Savings Bugs' Loom

Zonk posted more than 7 years ago | from the crush-those-critters dept.

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

cancel ×

403 comments

Things you should know. (5, Informative)

suso (153703) | more than 7 years ago | (#18040026)

http://www.bloomingtonlinux.org/wiki/DST_Time_Chan ge_Issues [bloomingtonlinux.org]

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. (5, Funny)

Anonymous Coward | more than 7 years ago | (#18040170)

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.
Mod parent down, informative.

Re:Things you should know. (3, Informative)

jcgam69 (994690) | more than 7 years ago | (#18040204)

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 [microsoft.com] , to all computers ASAP.

Re:Things you should know. (4, Interesting)

Ubergrendle (531719) | more than 7 years ago | (#18040256)

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.

Re:Things you should know. (4, Insightful)

shawn(at)fsu (447153) | more than 7 years ago | (#18040486)

Multiply 30 min x 1500 = 45,000 minutes, or 750 hours
Yeah that sounds about right if you do each machine one at a time. I should hope a datacentre is a little more efficient than that.

Re:Things you should know. (1)

harp2812 (891875) | more than 7 years ago | (#18040584)

I'm currently dealing with the same thing, but not quite to that scale (few hundred Windows boxes, 50+ *nix boxes).

Shavlik to push patches to the windows boxes, a short script to push & apply the patches to the *nix boxes... It'll be done in less than a week's time. :)

(And it's taking a week, only because we can't have any downtime and I have to play with load balancing, content caching, etc)

Re:Things you should know. (3, Insightful)

vadim_t (324782) | more than 7 years ago | (#18040578)

Why do your programs use the local timezone, anyway?

Programs should handle and store dates in UTC, and convert to the local timezone only for display.

FIRST!!! (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18040032)

FIRST!!!

Re:FIRST!!! (1)

Robot Randy (982296) | more than 7 years ago | (#18040586)

Obviously this AC hasn't patched his OS yet...

Bugs, Schmugs: Report Some Real News +1, True (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18040036)


Trivial compared to Grand Theft Nation [whitehouse.org] .

I hope this helps the criminal investigation.

Patriotistically,
K. Trout, C.E.O.

Makes me glad (0)

Anonymous Coward | more than 7 years ago | (#18040050)

I Live in Arizona where we are free from dynamic clock shifting.

Re:Makes me glad (1)

fitten (521191) | more than 7 years ago | (#18040266)

Except when dealing with things outside of Arizona :)

no need o worry (1, Insightful)

Anonymous Coward | more than 7 years ago | (#18040060)

daylight savings times and zones change constantly in australia and everything is fine here, no need to worry

Re:no need o worry (4, Funny)

lucabrasi999 (585141) | more than 7 years ago | (#18040804)

daylight savings times and zones change constantly in australia and everything is fine here

Everything is fine in Australia? Remember folks, this announcement is coming from the country that gave us The Wiggles.

Moo (1)

Chacham (981) | more than 7 years ago | (#18040074)

Just when you thought the Y2K bug was good, hours is better.

Will COBOL programmers be needed once again?

Re:Moo (2, Funny)

d3m0nCr4t (869332) | more than 7 years ago | (#18040508)

Oh Lords of Cobol, hear our prayers... So say we all.

y2k = media working for once (5, Insightful)

TinBromide (921574) | more than 7 years ago | (#18040094)

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.

Re:y2k = media working for once (-1, Offtopic)

Cedric Tsui (890887) | more than 7 years ago | (#18040338)

I hope one day, someone will be talking about global warming in the exact same way.

Re:y2k = media working for once (0, Offtopic)

SaDan (81097) | more than 7 years ago | (#18040388)

Me too, as we're freezing to death wondering how in the world the planet ended up in another ice age.

Re:y2k = media working for once (0, Offtopic)

operagost (62405) | more than 7 years ago | (#18040710)

Or global cooling ...

Mod Parent Up (2, Insightful)

ObiWanStevobi (1030352) | more than 7 years ago | (#18040370)

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.

rates? (4, Funny)

cascadingstylesheet (140919) | more than 7 years ago | (#18040116)


and cell phone-billing software could charge peak rates at off-peak hours


Aiyeeee!!!!!!!!!!!!!

Re:rates? (4, Insightful)

johnlcallaway (165670) | more than 7 years ago | (#18040180)

And could charge off-peak rates for peak hours. The number of hours for peak and non-peak will remain the same, only the start times will change.

Everyone wants a credit when they are over billed, but no offers to give money back if they are under billed.

Re:rates? (2, Insightful)

Nom du Keyboard (633989) | more than 7 years ago | (#18040228)

and cell phone-billing software could charge peak rates at off-peak hours

Why always the worst case is the one presented? They are equally likely to charge you off-peak rates during peak periods.

Re:rates? (3, Insightful)

Qzukk (229616) | more than 7 years ago | (#18040490)

Except that peak and off-peak mean something, namely volume of calls. So as a matter of fact, no, they are not "equally likely to charge you off-peak rates during peak periods" because you're more likely to be making a peak period call than an off-peak call.

Re:rates? (1)

Carbonite (183181) | more than 7 years ago | (#18040518)

They are equally likely to charge you off-peak rates during peak periods.

Maybe. This bug would cause some evening off-peak calls to be treated as peak calls (a 9:01 PM off-peak call is treated as an 8:01 PM peak call). On the other end, it would also cause some morning peak calls to be treated as off-peak calls (an 8:59 AM peak call is treated as an 7:59 AM off-peak call). I'd bet that more people are making evening calls than morning calls.

it is a real concern (2, Informative)

HP-UX'er (211124) | more than 7 years ago | (#18040126)

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.

Mod Freakin' Parent Up (2, Insightful)

Nerdfest (867930) | more than 7 years ago | (#18040412)

I've been on major rants for years with various people about having _everything_ maintained in UTC, using time zone localization only as a 'view' onto dates and times. The problem is, most people seem to think their own time zone is the center of the universe and don 't even realize that provblems occur even within one's own TZ because of DST variations.

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.

It is a VERY real concern. (1)

mmell (832646) | more than 7 years ago | (#18040500)

I have over a hundred machines to inventory - the hardware clocks are all set to UTC (as it should be), but the DST information still has to be correct so that the OS will report/record time properly. Also, I have (depending on the host) either one or two JVM's to ensure will be able to handle it (why does Java not simply trust the underlying OS to report time accurately?).

I don't mind checking the OS, but when I have to start looking at apps, that kinda gets my goat a little.

Linux? (-1, Troll)

scharkalvin (72228) | more than 7 years ago | (#18040134)

Hopefully Linux will handle this correctly if you have the latest
kernel or init scripts installed and have your timezone location set
correctly. M$ will use this as an excuse to force everyone to upgrade
to Vista!

Re:Linux? (2, Interesting)

profplump (309017) | more than 7 years ago | (#18040188)

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.

Re:Linux? (1, Funny)

TeknoHog (164938) | more than 7 years ago | (#18040258)

But I thought time would go faster if I compiled my Gentoo kernel with --omg-optimize!!1

Don't laugh (2, Informative)

wsanders (114993) | more than 7 years ago | (#18040678)

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

Re:Linux? (2, Informative)

n0dna (939092) | more than 7 years ago | (#18040474)

http://support.microsoft.com/gp/dst_topissues#a5 [microsoft.com]

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.

Re:Linux? (2, Informative)

VWJedi (972839) | more than 7 years ago | (#18040776)

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:Linux? (2, Interesting)

Larry Lightbulb (781175) | more than 7 years ago | (#18040610)

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.

Re:Linux? (1)

operagost (62405) | more than 7 years ago | (#18040768)

MS has released patches for the supported OSs, and you can use TZEdit to manuall patch NT 4. Please don't be ignorant.

Re:Linux? (1)

harp2812 (891875) | more than 7 years ago | (#18040774)

DST isn't handled in the kernel, it's handled in /usr/share/zoneinfo. Most recent distributions released patches for this back in late '05 or early '06. (Generally with a new tzdata package, and possibly a newer glibc) It can also be manually patched by downloading the latest tzdata file and running zic to compile & install it.

A site that will give you USEFUL Info..... (4, Informative)

8127972 (73495) | more than 7 years ago | (#18040142)

... On how to deal with this is below:

http://www.reganfamily.ca/dst/ [reganfamily.ca]

This is likely more useful than the original article. It has resources for everything from Blackberries to UNIX.

Not such a big deal (2, Interesting)

ThePolkapunk (826529) | more than 7 years ago | (#18040144)

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.

Re:Not such a big deal (1)

Gr33nNight (679837) | more than 7 years ago | (#18040332)

Im running into a similar problem with our 2000 machines. Willing to share that patch?

Re:Not such a big deal (0)

Anonymous Coward | more than 7 years ago | (#18040736)

same here - please share you 2000 patch!

This DST crap wouldn't be as big of a deal if it weren't for Win2000 and the whole Exchange/Outlook thing. Why the hell does Exchange and Outlook keep date info separate from the OS? Why isn't MS releasing a patch for Win2000 when they know there are still millions of people stuck on it?

Congress supposedly did the DST change to save money, but it's costing our org a lot of money already because we have to repeat the stupid Y2K scramble.

So THAT'S what's going on! (1)

Petersko (564140) | more than 7 years ago | (#18040466)

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

I knew it. All this smokescreen around energy savings is just a cover story.

Naturally Microsoft is behind the change. It's all part of their master plan to move people off of legacy OS's, or bleed dry everybody else.

How did I not see this before? Their tentacles are spreading ever further.

Re:Not such a big deal (4, Informative)

GogglesPisano (199483) | more than 7 years ago | (#18040572)

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 [intelliadmin.com] (as a bonus, it also supports WinNT).

Note that you may also need to update the Java JRE/JDK.

Brazil (1, Interesting)

Anonymous Coward | more than 7 years ago | (#18040146)

The summer time start/end date changes almost every single year here in Brazil, and the world doesn't end because of that. It will probably be a non-event, much like Y2K was.

There is no time bank (1, Informative)

Anonymous Coward | more than 7 years ago | (#18040156)

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

Ahem, Not Exactly (4, Informative)

Nom du Keyboard (633989) | more than 7 years ago | (#18040164)

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 (3, Informative)

FormulaTroll (983794) | more than 7 years ago | (#18040362)

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 (2, Informative)

FormulaTroll (983794) | more than 7 years ago | (#18040664)

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 [microsoft.com]

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

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

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

Cool (4, Funny)

Anon-Admin (443764) | more than 7 years ago | (#18040168)

And I thought that the year 1906 would pass with out any issues.

You're a year off, (1)

FirstNoel (113932) | more than 7 years ago | (#18040580)

It's 1907.

Re:Cool (1)

lucabrasi999 (585141) | more than 7 years ago | (#18040620)

Check your calendar. Around these parts, it's 1907.

Doomsaying? (3, Insightful)

eln (21727) | more than 7 years ago | (#18040184)

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.

Serious problem (0)

Anonymous Coward | more than 7 years ago | (#18040208)

Is this just more Y2K doomsaying, or do you think there's a serious problem here?
The Y2K issues was caused by of the lack of foresight of some programmers 20+ years ago. Fortunately We had decades to prepare for it, so it was very minor. This on the other hand is a legislated change for the sake of change. We had very little time to prepare for it, and nobody outside of congress could have foreseen it. Programs will break. People will lose money.

p.s. I tell my friends that the cynic in me believes that Microsoft paid off congress to get this passed to force everyone to upgrade to Vista. "We don't support that version of Windows anymore" == your timezone data is fux0r3d.

God, I hope not (1)

ObiWanStevobi (1030352) | more than 7 years ago | (#18040236)

I have a program that updates our Australia plant with new design files, some of which are modified within the hour of the last revision. The program uses a GMT timestamp for each file, and it will never overwrite an newer file with the older one. To get the timestamp, the program uses the Windows API. If Windows doesn't handle the switch, I'm going to have a lot of urgent work on my hands. So in answer to your question, yes not dealing with DST changes could cause lots of trouble! No, the issue will not resolve itself magically. Same with Y2K. People think it was a big hoax or FUD, but in reality, people really do have to work to fix these things in the background and never get credit for it when catastrophy doesn't strike. Hoepfully the OS programmers have been on top of it.

Solaris will be a problem? (0, Troll)

multipartmixed (163409) | more than 7 years ago | (#18040240)

Now that SunSolve patch access has been restricted to support-contract-holders-only..

How the hell do we update our old Solaris boxes that haven't had support in years?

Will they distribute new zone info files separately?

Re:Solaris will be a problem? (0)

Anonymous Coward | more than 7 years ago | (#18040506)

How the hell do we update our old Solaris boxes that haven't had support in years?
Pay Sun $400 per server [sun.com] or do the necessary timezone file updates by hand.

Older than Solaris 8 - pay through the nose! (1)

Fezmid (774255) | more than 7 years ago | (#18040602)

Anything older than Solaris 8 is not supported unless you want to pay $10,000/server (max of $150,000). Yup, you read that right.

Re:Solaris will be a problem? (1)

teknopurge (199509) | more than 7 years ago | (#18040634)

Computers and software is not meant to function forever. This is the price you pay for not refreshing your equipment.

Re:Solaris will be a problem? (1)

junster2 (573899) | more than 7 years ago | (#18040674)

Two words..

man zic

Similar (1)

trongey (21550) | more than 7 years ago | (#18040242)

The DST seems pretty comparable to the Y2K thing. There are some very real risks, but they are all fixable. Some are just nuisances like reports showing the wrong time. Other are significant like messing up work schedules for crews or causing batch jobs to happen at the wrong time.

I work at a very large company, and we're seeing a level of effort almost as big as the Y2K remediation, only on a much shorter timeline.

This is a typical government screwup:
1) create a solution to a problem that doesn't exist
2) neglect to study the ramifications of the solution
3) create a real problem that will cost millions of dollars to avoid/fix

Bermuda? (2, Insightful)

wiredlogic (135348) | more than 7 years ago | (#18040264)

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.

Re:Bermuda? (0)

Anonymous Coward | more than 7 years ago | (#18040442)

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.


Close to the equator? Take another look at a map. Bermuda is about as close to the equator as South Carolina is. Certainly isolated, though.

Small but subtle effect. (1)

Grimwiz (28623) | more than 7 years ago | (#18040270)

Computers have an understanding of what time it is separate to that shown to people visiting web pages, looking at the clock in the task bar etc... Well-written programs store time in its universal format, and convert the actual figures that you see depending on the viewers time zone.

This means that people who change the underlying clock to make the screen numbers look right will be causing more damage than good, Interesting effects can happen when the computer's internal clock goes backwards.

Of course, some programmers do not think outside of a simple computer, and just store information as they see it. The mixture of these two different ways of treating time may cause some odd effects.

Already has ramifications (4, Interesting)

michaelmalak (91262) | more than 7 years ago | (#18040280)

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.

Re:Already has ramifications (1)

Waffle Iron (339739) | more than 7 years ago | (#18040772)

Which raises the question: WTF don't JVMs get their timezone info from the OS? What were the developers thinking?

In general, I don't understand how people let this become a problem. The DST dates have already changed a couple of times within my lifetime, so I would never hard-code such a thing. This upcoming change has been scheduled for almost two years now, so every OS should have had this update in place long ago. Every app should be querying the OS for timezone info instead of hard coding it. How can so many people do such sloppy work so that there are still problems looming at this late date?

Over hyped!!! (0)

JimDaGeek (983925) | more than 7 years ago | (#18040284)

Just more FUD to get companies to worry and spend MORE money. That is all. I have been a senior programmer for more than a decade. Right after college, I took any-ole-job I could get. The job was for AIG, an insurance company. I was doing some new dev work, however, there was still a ton of Y2K junk going on that I had to waste my time with. So I had to do some COBOL work during that time (ewww). Anyway, the whole Y2K stuff was _way_ overrated. Could there have been some issues if there were not some programming changes? Yes. However, they were nothing like the press made them out to be.

This is just another "journalist" trying to get some name recognition. OMG..Teh..sky..is..falling!

From a programmers perspective, time zone stuff is pretty easy to work around.

Get rid of daylight saving altogether (4, Insightful)

Viol8 (599362) | more than 7 years ago | (#18040286)

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.

Re:Get rid of daylight saving altogether (1)

alphaseven (540122) | more than 7 years ago | (#18040632)

Thing is nobody wants to start work at 7 in the morning, so the government went out and renamed 7 as 8 for most of the year, and idiots think they're getting "more daylight" rather than getting up an hour earlier. Personally I'd rather everyone go on Greenwich Mean Time so I could start work at 13:00 and get off at 21:30, but apparently that's too confusing for some people.

Not a chance (1)

Programmer_In_Traini (566499) | more than 7 years ago | (#18040292)

Hey, there might be some other great task involved in banking or travel programs but in the end, i don't think its gonna do anything.

If i was paranoid i'd probably say this is a scheme to create jobs and make money.

I've been programming for 10 years now and programs don't generate their own time. well, I never created my own clock anyway, i don't see any need for it.

Whatever daylight saving changes do they are applied to the system clock and programs uses system clock. why would it matter when the OS decides its now 18h instead of 17h ?

The only instance where i can see this causing a problem is when programs monitors the time on a particular day, say the day where daylight is supposed to kick in/out. well that program would be screwed since now its 4 weeks later. But even then, it should be able to get the settings of the OS and not its create its own setting for that.

Its called internationalization settings (try to place that in scrabble) and its commonly accepted to get these settings from the OS just like currency and charsets because its generally not a good idea to create your own system when you've got an API right next to you waiting to help you.

Re:Not a chance (1)

turbidostato (878842) | more than 7 years ago | (#18040706)

"The only instance where i can see this causing a problem is when programs monitors the time on a particular day, say the day where daylight is supposed to kick in/out"

It shouldn't. You are right about no application having to deal with current time. They only ask the underlying OS "What time is it? and the OS answers "It's XX:YY UTC now"; that's all. And, ho and behold, the UTC second that follows the second prior to a daylight saving change is still one UTC second later, no time drift at all.

Except, of course, if you use an -ahem, OS that knows nothing about UTC and insists its showed time to be the same than the underlying system time.

Yes it is or could be a major problem. (1)

Grimfaire (856043) | more than 7 years ago | (#18040314)

We've already run into problems with this. It affects our CRM and our HR/Payroll software. And we're a small-medium sized company with an IT staff that can handle the problems quickly. If your staff can't, then it could be a big problem. You need to patch your OS to reflect the new changes so that items/people/etc get where they need to be at the correct time. This then can cause problems with applications that are not prepared for this. I've already had 2 apps break because of the OS patch. And I have a 3rd that will break if we install the OS fix so we're waiting for that app dev to provide an update. It's a lot like Y2K. If you prepare then it won't be a problem at all. If you don't, then you could have a ton of difficulties.

Progress (0)

Anonymous Coward | more than 7 years ago | (#18040342)

So congress changes time, affecting business around the world, but they refuse to introduce new regulations for other aspects of industry that actually impact quality of life. Hurray!

minutes, hours and days are NOT fixed values. (0)

Anonymous Coward | more than 7 years ago | (#18040414)

Due to the way our (broken) ancestral time system works, there are corrections: there are minutes that have 59 seconds or 61 seconds.

Then there are DST, where there are days that have 23 or 25 hours.

Which is why every single programmer in the programmer should store 'time' values as an integer value (say, in a 64 bit int). Use the milliseconds counter since the epoch (and, yes, the year 2037 [2038?] bug has been fixed since a long time ;)

Programmer that says: "do this on wednesday at 3h00 pm" and then store wednesday and 3pm are begging for troubles and deserve to be badly hit with a cluestick.

You store time in milliseconds, and you convert to/from when the data is inputted/outputted to the user.

This is what database do. Kids ought to learn.

Re:minutes, hours and days are NOT fixed values. (1)

Qzukk (229616) | more than 7 years ago | (#18040640)

Programmer that says: "do this on wednesday at 3h00 pm" and then store wednesday and 3pm are begging for troubles and deserve to be badly hit with a cluestick.

But if the government changes what 3PM means, that person's program will still do what the user (following the government's orders) expects.

You store time in milliseconds, and you convert to/from when the data is inputted/outputted to the user.

Good plan, but it doesn't take into account the fact that the number of seconds from the epoch to Wednesday at 3PM just changed for the four weeks that were affected.

Re:minutes, hours and days are NOT fixed values. (1, Troll)

lucabrasi999 (585141) | more than 7 years ago | (#18040730)

Due to the way our (broken) ancestral time system works, there are corrections: there are minutes that have 59 seconds or 61 seconds...Then there are DST, where there are days that have 23 or 25 hours.

And there's Nature's simultaneous Four Day Rotation in One Earth Rotation [timecube.com] . And don't you DARE try to match it!

I would never let Fedora change the time anyway... (0)

Anonymous Coward | more than 7 years ago | (#18040422)

Who cares! I would never let Fedora change the time anyway. It would screw up if Fedora, SuSE or Slackware would all change the time on my PC.

For most people it would be just an annoyance like I had when I noticed that each wanted to change the time. All you have to do is to change the setting for your winblows to not allow it to change the time and use your little fingers to do the job.

Temps Atomique International (1)

Nicolas MONNET (4727) | more than 7 years ago | (#18040424)

The solution is in /usr/share/zoneinfo/right/

Old OSes and Old JREs are the biggest concern (4, Insightful)

poopie (35416) | more than 7 years ago | (#18040462)

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

A round of applause for the tz guys (3, Informative)

Whiteout (828544) | more than 7 years ago | (#18040464)

The tz database http://www.twinsun.com/tz/tz-link.htm [twinsun.com] 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 [nih.gov] ) 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

I'm not gonna go any more. (1)

lucabrasi999 (585141) | more than 7 years ago | (#18040480)

Joanna: So, where do you work, Peter? Peter: Initech. Joanna: In... yeah, what do you do there? Peter: I sit in a cubicle and I update bank software for the Daylight Savings Time switch.

Re:I'm not gonna go any more. (1)

lucabrasi999 (585141) | more than 7 years ago | (#18040550)

Must....remember....to....preview....first

saving, not savingS (1, Informative)

r.binky (1065022) | more than 7 years ago | (#18040494)

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

Worse than Y2K because of Java (3, Funny)

wsanders (114993) | more than 7 years ago | (#18040534)

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.

UTC (1)

theguyfromsaturn (802938) | more than 7 years ago | (#18040538)

I always thought that operating systems and time-critical systems should always use Universal Time internally. It's fine to display stuff to the user in local time, but all the innards should be UTC. I loved my first Debian install when it told me how my computer clock was going to stay on UTC, and the display time would be acoording to whatever time zone I chose. Then I wondered why the heck Windows actually went and changed the hardware clock. That seems so stupid in retrospect. I'm sure some stuff would still be broken at some point, but keeping the hardware clocks on UTC and timestamps on UTC should avoid lots of trouble.

What about NTP? (1)

Darby (84953) | more than 7 years ago | (#18040540)

Assuming you set all your servers off of a local time server which is set off of an official time server, is this much of an issue?

I notice (1)

rsilvergun (571051) | more than 7 years ago | (#18040596)

that nobody's even considering the possibility that cell phone companies could charge off-peak fees during peak hours. That just doesn't happen.

We're all going to die... (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18040598)

horribly and in pain.

NTP for Everyone (2, Interesting)

Doc Ruby (173196) | more than 7 years ago | (#18040614)

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.

buy your water and duct tape now! (1)

peter303 (12292) | more than 7 years ago | (#18040636)

Just like Dec 31, 1999!

No big deal if you don't update... (3, Insightful)

thewiz (24994) | more than 7 years ago | (#18040650)

You'll catch up to the rest of us in three weeks!

yes, there is a bug (2, Informative)

kayditty (641006) | more than 7 years ago | (#18040658)

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

Local Time vs. UTC (1)

Detritus (11846) | more than 7 years ago | (#18040660)

I'm used to running and writing systems that use UTC for everything, including the user interface, because the systems may be installed anywhere in the world. How do you deal with "local time" in networked systems where the users insist on using local time? Even a small network may cross time zones. What about clock synchronization in Windows-based networks? Does it convert everything to UTC? This sounds like it could be a mess for companies that insist on presenting the user with local time in networked applications.

Apple (3, Informative)

metroplex (883298) | more than 7 years ago | (#18040692)

Apple just pushed an update through Software Update that fixes potential daylight saving time problems. You can grab it here [apple.com] if you use Tiger, or here [apple.com] if you still use Panther. It also released a similar update for Java. here [apple.com] is the Tiger version and here [apple.com] is the Panther one.

Insignificant impact (0)

Anonymous Coward | more than 7 years ago | (#18040728)

I haven't been too worried about missing some updates simple because there's really nothing bad that can come from it. Like most companies, we already deal with customers in multiple timezones so having to do a one hour shift until another update can go in will not catch anyone by surprise. Financial transactions don't reconcile until the end of the day so the exact hour they're put in really doesn't matter. The only thing I could think would be a problem is people that do automated messaging and stock market trades.

Nightmare (1)

MrSteveSD (801820) | more than 7 years ago | (#18040732)

Daylight Savings is truly a software development nightmare. I used to work on a product that had to read in data in clock time (i.e. like on your wristwatch) and convert into local time (always continuous with no clock changes). The system read in data in hourly chunks and had to work in the UK, Europe and elsewhere. It doesn't matter how clever people are, clock changes are always confusing. We'd be testing the system and always having disagreements over whether it was working correctly. Customers would also get confused and complain, then we'd have a big discussion with the customer with them usually realising that they didn't understand the clock changes properly themselves.

One of the big problems was that in clock time, one of the times occurs twice. e.g. you end up with two occurrences of 1.00 am when the clocks go back. You then have the issue of determining which one is which. You can treat them in order, but what happens if one of them is missing? Arghhhh!. You can start making demands of the customer like all BST (British Summer Time) times have "BST" after them, but usually you have to bend to the will of the customer rather than the other way round.

People made all that fuss over the millennium bug, but it's clock changes that really cause financial losses.

Conforming? (0)

zettabyte (165173) | more than 7 years ago | (#18040758)

Canada and Bermuda are conforming to the U.S.-mandated change...

That's right, Canada! You'd best conform! Don't make us come up there! We don't want to have to stop buying our meds from you!

And you too, Bermuda! Our corporations /will/ stop opening shell offices as tax shelters out there if you don't stay in line!

;-)

daylight savings time is stupid (3, Interesting)

circletimessquare (444983) | more than 7 years ago | (#18040770)

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

Already bit me, MS did NOT patch correctly (0)

Anonymous Coward | more than 7 years ago | (#18040780)

The patch MS released makes windows think DST has always worked how it will this year. This created a bug in my application, which uses recurring dates. An entry scheduled at 11am March 15 2006 to recur every week now shows up at 12am. The reason being that the patch has changed it so now that original March 15 date is now considered in DST, pushing it from 11am to 12am.

Reports generated rely on this information being accurate, so I cannot just go back and move the date into a false time to accomidate Window's DST bug. Also that would affect the Linux machines accessing it which arn't affected and see the date correctly.

What a global mess (1)

Kawolski (939414) | more than 7 years ago | (#18040802)

Worldwide daylight saving [webexhibits.org] -- In a world where we're doing things in real-time with people around the globe, this is an annoying mess with different countries observing DST at different times of the month. For the love of God, just standardize it internationally or don't do it at all!

I look forward to when this DST map [wikipedia.org] is completely red and orange.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...