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.
I Live in Arizona where we are free from dynamic clock shifting.
daylight savings times and zones change constantly in australia and everything is fine here, no need to worry
Just when you thought the Y2K bug was good, hours is better.
Will COBOL programmers be needed once again?
Have you read my journal today?
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.
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.
It's daylight saving time, not daylight savings time. There is no bank. Or spoon.
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.
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.
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.
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?
Do daemons dream of electric sleep()?
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
You never really know how close to the edge you can go until you fall off.
But I thought time would go faster if I compiled my Gentoo kernel with --omg-optimize!!1
Escher was the first MC and Giger invented the HR department.
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.
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.
-- Don't believe everything you read, hear or think
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.
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.
General, you are listening to a machine! Do the world a favor and don't act like one.
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.
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.
If you look like your passport photo, you're too ill to travel. - Will Kommen
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.
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!
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.
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.
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.
The solution is in /usr/share/zoneinfo/right/
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
"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.
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.
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.
We are only saving one thing, daylight. There is no plural on saving. Daylight Saving Time.
I don't mind checking the OS, but when I have to start looking at apps, that kinda gets my goat a little.
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?"
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.
I like my dinosaurs feathery, and my pterosaurs hairy (or is it pycnofibery?)
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?
It's 1907.
"Hmm. I am to metaphor cheese as metaphor cheese is to transitive verb crackers!"
Obviously this AC hasn't patched his OS yet...
that nobody's even considering the possibility that cell phone companies could charge off-peak fees during peak hours. That just doesn't happen.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
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.
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
Just like Dec 31, 1999!
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"?
It is Daylight Saving Time, and not Daylight "Savings" Time.
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.
Mea navis aericumbens anguillis abundat
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 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.
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.
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!
;-)
MS has released patches for the supported OSs, and you can use TZEdit to manuall patch NT 4. Please don't be ignorant.
Gamingmuseum.com: Give your 3D accelerator a rest.
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
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.
I've found that nurturing one's Zen nature is vital to dealing with technology. Violence is pretty damn useful too.
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?!
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.
Worldwide daylight saving -- 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 is completely red and orange.
It is not *that* big a problem for most people ,your average home user. For locations like where I work, our login auth system is time-based, so if the computer is readying 9AM and our clocks are reading 10AM, then it's a problem. For the most part, I would hope that most bank and transportation systems would have this worked out already.
You need to "yum update tzdata" or whatever.
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?"
Yeah, it sucks that they are making you pay extra, but how does that compare to paying your high priced IT staff to develop a custom solution?
Netware was awesome for that. We did all 20 Netware 6.5 servers in about five minutes total. Everything related to DST is stored in a text file. Novell even provided a script that would change them for you.
Jason
"FORMAT C:" - Kills bugs dead!
I just realized that if I were OJ, and I did it, I'd stand around a camera with a DST bug, and then go kill that bitch. And get off scot-free, m-fers! Scot-free!
Please stop stalking me, bro.
It's the subtlety of the issue in Java that's a problem. If one were really sharp, one might assume that Date.equals() also compares time zones -- but who would've guessed that also the time zone rules would have been compared in Date.equals()?
Canada and Bermuda are conforming to the U.S.-mandated change
Even though the Canadian government rolled over and is forcing us into a dubious and probably un-needed change to our DST, I feel obliged to point out that the US does not "mandate" time zones in other countries (well, perhaps in Iraq, and I wonder if they're also changing how they handle DST)
Certainly the US tried to strong arm Canadian businesses and government on this one, but in theory at least we still control our own clocks.
Three Squirrels
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?"
I saw (nearly) the exact same article in the St. Louis Post Dispatch, who only talked about Microsoft and Apple (no problems with either if you're running Apple or XP2). At least ZD mentioned some other companies.
I'm pretty sure I'm ok, as I have Mandriva check a time server on boot. But what if I wasn't connected to the internet?
And what about my TV and VCR?
-mcgrew
Glad our main business application system has had this covered for like "FOREVER".................
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.
Daylight savings is obsolete and pointless. As I was informed it was used back in the 19th century for farmers to gain more daylight business hours. Today this is pointless and only causes people to have to adjust their whole life to either an hour later or earlier.
Y2K bugs was a very, very serious problem.
Through the efforts of myself and countless other programmers and IT workers, it was fixed.
I saw many systems test, crashed a few systems, and watched finance calculations go nuts.
Is say it gain: Y2K disasters didn't happen because they were, mostly, fixed on time.
DOn't say nothing happened therefore there wasn't an issue and all those people putting in all those hours were for nothing.
Yes there was media hype, but that didn't mean there wasn't a real problem.
As far as this new time change is concerned, there are problems because mexico isn't doing it, So thge airlines have to account for that. Does that mean planes will fall out of the sky? no, but scheduling is going to be a nightmare.
The Kruger Dunning explains most post on
You're right. I misread that.
However, my argument still holds against the parent. The fixes are available, requiring payment or not. No one is being forced to purchase Vista to solve it. Apple is only providing fixes back to 10.2. Does this mean Apple wants you to upgrade to Vista too? He just wanted to take a cheap shot at MS.
FWIW, I personally don't have much sympathy for someone running an 8 year old OS that was EOL'd over 18 months ago. If it does what you need it to do, fine, I'm happy for you, but you can't complain about it being left out of new requirements or advances.
Why not make your case that it's the Gov't issue to solve for you since it's congress that's requiring the change?
Reduce, reuse, cycle
I think a lot of people are missing one of the biggest pains out of the DST change, which is meetings booked in an exchange environment. Even if you do everything Microsoft/RIM recommend, and do them within hours of each other (a very daunting task for any enterprise sized environment,) you will still have meetings off by an hour.
This can be caused by lots of reasons. If one desktop recieves the patch and sends a meeting to another user, who has not received the patch, the meeting time will be wrong. Even if you manage your DST updates flawlessly within your environment, and don't have any misplaced meetings, you have no control over any external sources that may be booking meetings with your users. It's pretty inconceivable that everyone will update at the same time.
I really don't want to be the one on the CEO's warpath the first time he shows up for a meeting early/late. These issues can be partly resolved by user education, but as another poster mentioned, it is very easy to get confused when talking about timezones. I've been working on our DST project, and I still need to think carefully every time I discuss the ramifications.
I think Cnet had it right when they wrote that users should add this to their signature:
'Please note, if I (am) an hour late or an hour early for my meeting with you, please understand, its not my fault, it's my government.'
You would have to restart every application that is using the old zone. Everytime it wants to convert system time to localtime it does not reread the zoneinfo files.
At that point you might as well reboot the system.
This means Linux and FreeBSD are not immune to the whole timezone reboot issue. (correct me if I am wrong, please!)
“Common sense is not so common.” — Voltaire
When I heard our congress critters wanted to extend day light saving time my first reaction was WTF! Why are they imposing another useless Y2K'ish problem for us to work around. I'd be happy if they would just GET RID of the fsking thing. My second thought was, what about all the time sensitive operations carried out by embedded systems and all the OS flavors out there that patches will be hard to impossible to get.
Guess I'll just have to set all the clocks manually or start using UTC. To me, DST is another useless hold over from a previous century.
"I bow to no man" - Riddick
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?"
There are a lot of embedded systems out there that could be impacted by this, so it would be prudent to consider the impact should a component fail. Back during the run-up to Y2K I was doing embedded systems assessments for upstream oil and gas producers, and during an inventory of some SCADA systems on an off-shore oil rig a rep from one of the equipment manufacturers happened to be there while we were. We got to talking about a specific component and he emphatically claimed that the component was Y2K ready and said "here, let me show you". He manually advanced the date on the device to February 2000 and it immediately failed. You should have seen the commotion as the crew scrambled to maintain the appropriate functionality of the rig manually. To the rep's horror he discovered that he could not set the date back on the device (it was a $15,000 piece of equipment). Fortunately the oil rig had a spare in inventory and it was installed within a half hour and order was restored. Of course we thanked him for helping us with the assessment.
then the answer is Phoenix.
Not only will the IT dept be busy but personal computers will also have problems. I agree it's a little over-hyped and the easiest thing for a Windows user might be to just disable the automatic DST adjustment and force an update. Retrevo.com put together a good resource page for PC info and CE gear. http://www.retrevo.com/setyourclock
I worked on the Y2K bug, and I think that 20 years from now, one of two things will happen. First, the one that everyone assumes will happen, is that it will be remembered as a big non-event. There will be some who point out that without the work that went into it, it would have been a huge crash. But you can't prove it now. The second option: I like to think that one day, historians will look back on it as the most successful software project in history. Think about it - a software project that was enormous and had an immovable date. And it came in on time and succeeeded beyond anyone's expectations. I hope that the media will wax nostalgic on it, cover it in the light of a heroic effort that was a brilliant success. Maybe we weren't the "greatest generation" but I hope that one day, the people who made Y2K a non-event will get the lavish credit they deserve.
Brawndo: It's what plants crave!
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.
% 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
However, my argument still holds against the parent. The fixes are available, requiring payment or not. No one is being forced to purchase Vista to solve it.
That's the rational explanation. However, what do you think Microsoft's marketing department is going to say about the DST changes?
[begin commercial; speaker is James Earl Jones or another with a strong/imposing/authoritative voice. The screen starts off showing images of dramatic failures (plane crashes, the Hindenberg, etc.) and moves to pleasant scenes of success for the second sentence.]
If you're still using Windows 2000, you should know that the programs on your computer, or your whole computer itself, could stop working or return incorrect results as a result of the DST changes. Windows Vista, however, uses new and improved technology that means that your computer will be safe when the DST changeover occurs. Windows Vista. For when you absolutely, positively have to get the right time.
[end commercial]
Whether you think it was overhyped or a train wreck averted, you have to admit that Y2K helped bring IT issues to the radar of C-level execs, along with loads of cash. In addition, it also soaked up a lot of the "classically" trained CS majors and top programmers. That created a vacuum for a lot of underexperienced/self-trained programmers (like myself, at the time:) to slip into the workforce and get exposure to new technologies, advanced roles, and above-average pay. If another little tremor in the computing economy does the same, justified or not, it's fine with me. Whether it's this or the "bird flu will bring teh Internets to its knees," there should be plenty of changes in the ongoing IT economy to keep it from stagnating too much.
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.
I'm all for UTC, but I also am someone who does not wear a watch, and I generally don't care what the time is. All I care about is that we all agree on what time is what.
Some people check the time regularly and have very strong feelings about "lunch is at 12," etc. I suppose they are our opposition.
Spoon not. Fork, or fork not. There is no spoon.
AFAIK Apple is only providing fixes for 10.4.x. I patched my 10.3.x systems with an open-source tool some helpful person created.
I think they'd prefer that you upgrade to Mac OS 10.4.x (Tiger) or 10.5.x (Leopard).
I understand if they say, "It's EOL'd so we're not going to expend any resources fixing it." But it looks more like they're saying, "We've expended resources fixing this for people who have paid for extended support. You can (a) pay us money to get the fix or (b) pay us money to get Vista." That sounds like extortion to me.
Didn't they do this last year?
Saving. No "s" at the end.
http://en.wikipedia.org/wiki/Daylight_saving_time
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!
Yes, there COULD be a problem. Every year my systems go through this twice and every year there are problems.
There is a solution. We call it SCRIPTING. Here's a sample
if (DATE()=$DSTChange_Date && $time(now)=> 23:59) {
set TIME(1:00 am);
}
Of course that script won't work. For the REAL solution, send $12.95 US to:
Here will be an old abusing of God's patience and the king's English.
You only have to restart things that cache a copy of the time zone data and can't be convinced to re-read that file with a HUP (or other limited-interruption reconfiguation signal/command). Some things (fcron and syslog for example) really needed to be killed. Other things I tried (Apache, Samba) seemed to do okay with a reload command -- or at least that's what I got from the open(/etc/localtime) that strace showed me, I guess we'll see in a few weeks. Most low-level long-running programs (init, watchdogs, etc.) don't care much about time in the absolute sense, and relative times still work out fine without updating.
And if you're running a system that takes 10 minutes to get all the hardware up and settled, even killing everything under init is preferable to genuine reboot.
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
If I ever become a rich and powerful politician, I'd change the date on a regular basis. "Oops, I guess I shouldn't have pushed that button. Let's see, that happened on the fourth, but I also got a ticket on the third... major hangover New Year's..."
"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
but I'm putting everything I have into shotguns and canned goods.
:)
You young whipper snappers probably don't remember it, but Y2K was a nightmare. Planes crashed.
The stock market crashed. Facists took over the Whitehouse. Ramapant violence in the middle east.
Cannibals roamed the streets, inviting the unwary to a bar-b-cue. Dogs and cats living together in sin.
putting the 'B' in LGBTQ+
in the worst-case scenario for y2k, banks mess up transactions because it's the wrong year. but time keeps going in a straight line.
there are countless time-keeping applications out there that don't care what year it is, just if 15 seconds have passed or 15 minutes. cron, at, and other system scheduling apps run jobs based on what time it is, and almost nobody puts what year it's supposed to run, because it's continuous.
just think of every cron job on every server in a bank, in grocery store point-of-sale systems, in automated alarm and sprinkler systems, VCR recorders/TiVo's, god anything with a timer! y2k was never going to hurt those systems because they didn't hinge so much on a year as a time in general.
however the same stuff y2k was going to affect will also be hit by this change, like filesystems which record file time/date stamps, billing systems, etc.
this is much worse and the media is ignoring it.
http://www.swatch.com/internettime/home.php Whip
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*!
>This completely ignores a VITAL fact... computers are binary, NOT decimal.
Many, many systems use some form of BCD, especially for dates.
-fb Everything not expressly forbidden is now mandatory.
Did you know that the sporting goods industry and BBQ industries lobbied heavily for lengthening the period of daylight savings time?
The longer daylight lasts after people get home from work the more they play outside and BBQ and therefore the more products they buy to support those activities.
"It's a conspiracy, I tells ya!"
Yeah, it sounds like tinfoil-hat thinking but if you followed the lobbyists the last time the US increased the number of days affected by DST those industries were prime backers. I wouldn't be surprised if they were involved this time too.
You only have to restart things that cache a copy of the time zone data and can't be convinced to re-read that file with a HUP
It's not really up to the program itself -- libc handles the timezones and as far as I know there's not an API that allows an application to tell it to re-read the files.
Other things I tried (Apache, Samba) seemed to do okay with a reload command
Apache I'm pretty sure implements reload by exec()-ing itself, which effectively is the same as killing and restarting it. I'm not sure what Samba does but I suspect it's something similar if it caused the timezones to refresh.
This isn't like Y2K at all, with Y2K there was a "physical level" risk of overflow from 2 digits to 3 digits, this isn't the case here. Also in Y2K there was a fear that say 1900 would get displayed as year, this is only an hour wrong so at worst it will be transactions around midnight that might cross the day/month/year boundary but fact is that very few automated programs rely on such precise datetime stamps (& those that do probably use UTC at storgae lvele). As is most servers are quite a few minutes off so a whoele 60 won't be catastrophic.
I was on a website a couple of days ago that showed the current year as 19107. Guess the Y2K memo went missing for that administrator.
And in the end, the love you take is equal to the love you make
This is not true, especially in mainframe systems dates are usually stored as either a julian format YYYYDDD or gregorian YYYYMMDD format. Each segment is not stored in a separed binary number, that would have been extremely wasteful of space not to mention cumbersome. Instead dates are stored as a single numeric field formatted and in non Y2K compatible software this means they were stored as YYDDD or YYMMDD.
If these were used in date arithmetic using non Y2K patched software they would indeed return erroneous results. Often in software the question is asked "is date X before date Y?" The usual way of checking this is to compare the entire date field as if it were a single number. If date X is "greater than" date Z then date X happened after date Z. If you only have 2 digit years the answer is incorrect if the two dates span the century. This kind of logic is ubiquitous in many mainframe systems and required a lot of patching.
Didn't compile right on this really old debian I had to patch (3.0). The "northamerica" file looks OK though, but it generated America/* files with the old dates for 2007 somehow.
In general, compiled zoneinfo files are transportable between systems. It was easier to just copy the already-compiled zoneinfo file from an already-patched host, in this case a Solaris host, even, and copy it to the ancient one.
Be sure to check the zoneinfo file with zdump.
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?"
It's "Daylight Saving Time" NOT Savings...
http://en.wikipedia.org/wiki/Daylight_saving_time
I understand if they say, "It's EOL'd so we're not going to expend any resources fixing it." But it looks more like they're saying, "We've expended resources fixing this for people who have paid for extended support. You can (a) pay us money to get the fix or (b) pay us money to get Vista." That sounds like extortion to me.
You are completely incorrect if you believe it is extortion. Basically they are saying if you really need support for EOL'ed software then it is going to cost us money and we are passing that cost onto you. I know that if someone came to my company and wanted us to support really old versions of our software that I would charge them money too.
Lets say they just decided to not support it at all, well that would possibly cause huge problems for some companies that still rely on the EOL'ed software so it is nice for MS to still support them. However, if they just let anyone have access to the EOL'ed support then there would be little reason for people to upgrade to software that is regularly supported and it would be a big cost for MS to keep supporting such old software. This is a nice compromise that lets people who really need the EOL'ed support get that support for a price while MS doesn't have to carry the cost burden of that support or alternatively just not support it at all.
Hey, there is only one Return and it's not of the King, it's of the Jedi.
> 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.
Well, I don't believe it's extortion in the legal sense, but it certainly doesn't give me a warm, fuzzy feeling.
I see your point, but I'm not sure there is a "right way to do this". In my mind, it all depends on how much it cost MS to fix Win2000... If a couple programers back-ported the XP fix in an few hours, then they're charging way too much. If 50 people spent months writing a patch for Win2000, then it seems perfectly reasonable for MS to charge a reasonable price for it.
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.
A specific comment followed by a few general points.
Back in the 80s in COBOL we coded all our dates as PIC S9(5) COMP-3 which would be stored in 3 bytes. That is YYJJJC (IIRC) YY- year JJJ - julian day and C - sign as hex values. These dates also have the advantage of being easily sorted. This made a big difference in space and processing efficiency, especially when there were a large amount of tapes involved. They were also easy to pick out in dump printouts when you code abended as there was no binary conversion required. When I enquired about what happens in 2000, the response was that all the code would have been rewritten by then. I guess that happened but maybe not in the way envisaged.
With respect to date storage issue now, as long as there is a clear method of converting the stored date to the localtime (like POSIX epoch time) then it is a matter of keeping your OS up-to-date.
Surely embedded devices are not programmed to work in one time zone. Unless your devices hooks in with a time service that can update the localtime mapping information, manual intervention is required.
In Australia, we are used to the state governments fiddling with the DST start and finish dates on a nearly annual basis. Me, I love mornings so I can live without DST.
Slashdot: Where nerds gather to pool their ignorance
An hour off is critical, however financial firms have something called compliance officers who the instant this thing was stated should have started trying to fix it. Microsoft has released patches for it, so now we should be set.
Basically this is only going to be a critical bug if people ignore it just as Y2K was going to be a critical bug if people ignored it. Overall we should all be fine, but if you're in IT it's worth checking to see if your taking adequate precautions about now. Not later.
Btw if you're running a server farm and having figured out a way to apply microsoft patches (which should solve most of your problems, you ARE running stuff off a system clock and you are syncronizing that system clock, arn't you? If you're using anything else it should more precise than the system clock.) in a near automatic that's your problem, not the fact you have a 15 minute patch.
I'm posting this from about 1 degree West of Greenwich...
Note:
When you change your daylight savings time rules-- there is no effective date so the rule applies backwards as well as forwards. Any reports you recalculate based on GMT converted to DST will not match the originals if hour by hour matters.
In other words, as of march 11th, 2007, the current DST rules also apply to March 11th of 1970 (when the change was really in April).
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
"I told ya not to hard code it in there."
Just be glad we aren't on "war time" or something like that.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
The bank I use still uses two digit dates on its paper forms. That was the root cause of Y2K and nothing was actually done about it.
Incidently leap seconds are a big problem for ATC systems. When your radar and radar processor are synchronised from GPS a one second skip in the synchronised time can cause chaos.
http://michaelsmith.id.au
Users don't set their watches to UTC though.
Yes, but Slashdot users do. Well those not using decimal time anyway.
spoonerize "magic trackpad"
..but the effects are repeated every year.
-- All your bass are below two Hz
One difference between a zoneinfo system and some other systems is that you can update the zoneinfo file long before the actual change.
There is no need to patch it in the months before the change, it can be done years before (assuming the upcoming change has been decided).
So, you can patch your system in february 2006 for a DST change that will take effect in march 2007. The system will probably be rebooted after the patch and before it becomes critical. You only need a reboot just before the DST date, on the systems that were not rebooted after you patched.
Metric is abitrary, but it's rest of the world arbitrary! :-) (umm I think there's only three or four countries in the world who don't use it officially*)
So assuming you trade with the rest of the world, that's one argument for metric. You can buy engineering / mechanical components from other people's production lines and fit them onto your kit. You can get your engineers to collaborate with their engineers and not have wrong assumptions about what units are being used (and hence avoid rather unfortunate screw-ups as you note, poor ole NASA).
* I know a good few places use a mixture of systems unofficially but I'm referring to your "engineering/machining/manufacturing perspective"
For the love of all that's unholy, it is called Daylight Saving Time not Daylight Savings Time ...End of Line...
Think of me when you shave your legs...
I'm one of the "linux guys" so I was involved in our own internal evaulations of the DST issue.
Basically, what it boils down to is widespread minor problems. It's not like Y2K where things are supposed to just blow up and the world ends. Time sensitive apps will be out of sync for a month if the patches are not done. There is a real problem with older versions of Java. Recent versions have zoneinfo files that can be updates, but old versions of java handle time zone conversions internally and there are no zoneinfo files to fix.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
I once saw a really good collation of many time boundaries that were expected to cause potential problems based on different ways of storing and interpreting time data. Y2K was one of them, the 2037 bug was another, but there were probably about another 20 or so dates in between that were listed as potential problems.
Unfortunately I lost the link. Does anyone have a link to a list like this?
If you are working in the mainframe world then this will cause you some serious pain until it is worked out exactly how you should deal with it. To give you an idea: Our solution (sorry, abrev version and I don't run this side of it - I only hear about it) is to turn everything off for an hour to avoid the issue altogether. Multiply that by several LPARs and x number of midrange (read: Java) boxes and it starts to add up. Not to mention the cost of having a 'special job' done at 3am by your outsourcer.
For those who are wondering, yes: we do have many other bits and pieces to address to handle the daylight savings problem. Even with the forward jump we still need to pay careful attention - time changing can cause lots of problems (especially when database entries and processing timestamps are affected). Yes, we do power down for an hour on the jump forward - just to avoid the issue altogether.
You have a sick, twisted mind. Please subscribe me to your newsletter.
At least we have 30 years to fix that, a lot more than the year and a half we had to get ready for this one.
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
The worst part is that this is completely avoidable. The US didn't have to change its DST rules. All this busywork and patching and fixing was created by legislation. Thanks alot for all the lost productivity, Washington...
DST is pointless, anyway. Let's eliminate it. If there's really such a big advantage to starting and ending the workday an hour sooner, won't smart businesses do it on their own for the giant savings they'll get? But since we all have to be forced into it, I'm guessing the advantage is negligible. How much does the lost productivity of missed meetings on the two changeover days, and the money wasted on accidents caused by sleepy drivers, factor into those benefit calculations, hmmmm?
Constitutionally Correct
http://web.mac.com/jamiecox/iWeb/Florida%20Dayligh t/Welcome.html
Computers obey me.
I just hope they use two digits for cent calculations, and not floating point numbers.
Although, it would make saying "My account has about 10 cents, more or less" a bit more accurate.
Oops. What I mean is, the only day there could be "six" hours between 0100 and 0600 is the day DST ends. So there will be a problem--but only if the local timezone doesn't change. Since we're trying to get these patches in before DST starts...
There is a fine line between recklessness and courage... -- Paul McCartney
Couldn't this problem (and future time problems) be solved just by using a time server that has the patch installed?
I thought the UK was always on DST. Are you saying they are piling a second DST (aka "Summer Time") on top of the first?!
If so, then we have an argument not to make permanent DST in America...
There is a fine line between recklessness and courage... -- Paul McCartney
The best way to distribute a relatively small database to hundreds of millions of computers is probably through DNS. It's ubiquitous, reliable, efficiently cached by ISPs and contains a built-in system for delegation of authority.
Some organization would need to manage the top-level authority and coordinate the encoding and naming conventions.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
I strongly agree: the fix for any version of Solaris, and in principle any other machine with zic and zdump, is
#
#
$ zdump -v Canada/Eastern | grep 2007
#
#
davecb@spamcop.net
... 32-bit extension to a 16-bit patch for an 8-bit operating system that was originally coded for a 4-bit microprocessor by a 2-bit company that can't stand 1-bit of competition.
- Disclaimer: Information in this post deemed reliable but not guaranteed.