Slashdot Mirror
Y2K: Hoax, Or Averted Disaster?
Allnighterking writes "Y2K -- remember the fear it generated? Cartoons were written about it. The dried food industry saw a boom. Doomsayers abounded. But in the end, no planes fell, no one died and the electric grid stayed up for three more years. Was it all a hoax? Or was it the result of careful and complete planning and upgrading. American RadioWorks has a series of articles talking about the disaster that never happened called Y2K You can either Listen in or read the Transcripts of each of the 3 broadcasts and decide for yourself. The over 100 Billion pumped into the US economy alone may well have fueled the boom and predicated the bust. Could the success at Y2K prevention have made the coming problem in 2038 something people will ignore?"
I think it had a snowball effect : people inconsciously feared it and their fear grew while they heard even more about it. So it's not only the media, it's also people.
Trolling using another account since 2005.
"the coming problem in 2038"
Phil Collins is going to release another album?
"The dew has clearly fallen with a particularly sickening thud this morning"
2038 is years away - we'll all have new systems by then! No need to worry!
Was it all a hoax? Or was it the result of careful and complete planning and upgrading?
How about the combination of the two? I remember seeing Y2K companies trading on the stock market with $10 billion market caps. But then I remember hearing legitimate stories about real world fixes.
It is like the Tsunami. Lots of people are going to make money unethically but, ultimately, we can't stop them unless we just cut off all help.
More
The site seems to be slashdotted already..a 81bc488a392/index.html
mirror: http://mirrordot.org/stories/c3714b90fba0ed06b444
I'm an old-time mainframe guy, started coding back in the late 70's.
Anyway, back in those days we had a problem every four years. Yep...you guessed it, some programmer had forgotten to take leap year into account.
And when that happened, programs broke. We fixed them in a few minutes and we were on our way. But companies didn't stop. Planes didn't fall out of the sky. Nothing bad happened, other than annoyed users and managers.
My point is that programmers have been screwing up dates and date routines since the computer was invented. We had instances of all the programs breaking on one days. And yet, nothing bad happened.
Hoax. Great for my career....I got a big house with a pool, and a BMW out of the whole Y2K thing, so I'm not complaining. But lets face it, it was a boondoggle.
I personally blame Yourdon. But only because the man is a complete idiot.
Lets see, I'll be 73 about then.
Providing it doesn't cause my VTOL (Vertical Take Off and Landing) 200 mph Zimmer Frame to crash, I don't really think I'm going to care all that much.
that people don't believe in things they can't see. they can't 'see' spyware so it's an imaginary problem. same thing with viruses. they don't believe until something bad happens.
it's the same mentality the apparently caused countries in the indian ocean region to decide that a tsunami warning system was not a high priority.
there was a time in early/mid 2000 that i got so tired of people deciding that y2k was a hoax that i wished really bad things had happened.
eric
Well Y2K stopped our overtime system from working - we had to enter dates in from 28 years ago. It also stopped a (time-limited) graphics editor that I wrote from working - it was due to stop at 31/12/1999 but the time-bomb code didn't handle further dates properly anyway! Dang DOS API calls...
The tsunami was a relatively small scale event, affecting mainly small islands and long coastlines, but the backup effects (refugees, lack of drinkable water, damage to communication networks, the need to divert resources and the difficulty of doing so) will doubtless result in many more people dying over time. In the same way, I suspect that if we had done nothing about Y2K, the cumulative result of a lot of small disruptions would actually have resulted in major economic loss and many people dying.
Panurge has posted for the last time. Thanks for the positive moderations.
Certain code would do the wrong thing on date rollovers and needed fixing - I'd seen it myself.
:-) Globally there were one or two, but nothing major.
The seriousness of the problem was exaggerated by the following misconceptions:
1. Everything that held a date in it with 2 digit years was going to have a problem.
2. Everything described in point 1 that was not fixed would fail in the most disastrous way - missiles being launched, planes falling from the sky.
In reality there could be no problem, or the problem might only be cosmetic. For example, a system I was testing would show the wrong status colour (meaning you haven't done a diagnostic in so many months) but it would not do anything wrong. Still, it had to be fixed to be Y2K ready.
Nonetheless, I was slightly under whelmed by what went wrong on the day. I knew society was not going to collapse, but I expected a few non-critical SNAFUs. I made sure I took out cash from the ATM before New Years, but I gave the water supplies and the bomb shelter a miss
${YEAR+1} is going to be the year of Linux on the desktop!
(Shamelessly stolen from http://www.gsp.com/2038/ )
Spelling mistakes: My is english spoken not tongue of mother.
Update: 01/2004 The first 2038 problems are already here. Many 32-bit programs calculate time averages using (t1 + t2)/2. It should be quite obvious that this calculation fails when the time values pass 30 bits. The exact day can be calculated by making a small Unix C program, as follows:
In other words, on the 10th of January 2004 the occasional system will perform an incorrect time calculation until its code is corrected. Thanks to Ray Boucher for this observation.
The temporary solution is to replace all (t1 + t2)/2 with (((long long) t1 + t2) / 2) (POSIX/SuS) or (((double) t1 + t2) / 2) (ANSI). (Note that using t1/2 + t2/2 gives a roundoff error.)
The year-2038 bug is similar to the Y2K bug in that it involves a time wrap not coped for by programmers. In the case of Y2K, many older machines did not store the century digits of the date year, hence the year 2000 and the year 1900 would appear the same.
Of course we now know that the prevalence of computers that would fail because of this error was greatly exaggerated by the media. Computer scientists were generally aware that most machines would continue operating as usual through the century turnover, with the worst result being an incorrect date. This prediction withstood through to the new millennium.
There are however several other problems with date handling on machines in the world today. Some are less prevalent than others, but it is true that almost all computers suffer from one critical limitation. Most programs use Coordinated Universal Time (UTC) to work out their dates. Simply, UTC is the number of seconds elapsed since Jan 1 1970. A recent milestone was Sep 9 2001, where this value wrapped from 999'999'999 seconds to 1'000'000'000 seconds. Very few programs anywhere store time as a 9 digit number, and therefore this was not a problem.
Modern computers use a standard 4 byte integer for this second count. This is 31 bits, storing a value of 231. The remaining bit is the sign. This means that when the second count reaches 2147483647, it will wrap to -2147483648.
The precise date of this occurrence is Tue Jan 19 03:14:07 2038. At this time, a machine prone to this bug will show the time Fri Dec 13 20:45:52 1901, hence it is possible that the media will call this The Friday 13th Bug.
I work for an international bank and we fixed 2-300 Y2K bugs. I know; I tested the changes & found more doing the testing. Obviously, some were more critical than others. We also upgraded release levels of system software. I also know that some were missed. The thing is, they were attributed to something else when they occurred. Noone would admit that they had missed a Y2K bug after all the $$$ thrown at the problem. I'm sure my situation is not unique.
Y2K hasn't come yet. As any coder ought to know, 2K == 2048, not 2000.
Nothing to see here. Move along.
No money was pumped "in" to the US economy. Money was merely moved from one use to another.
While the economy gained from the new spending, it lost from the lack of the default spending.
Without any hard data, one should assume that this was either a wash or - more likely - a net productivity hit.
People make this mistake all the time: "ooh! hurricane! I bet all that spending on new windows helped the economy!". No, it didn't. It took money that would have otherwise been spent at restaurants, book stores, etc., (or left in banks and brokerage accounts, where it helps build other sectors of the economy) and moved that money into glass repair shops and plywood factories.
Don't fall for the myth.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
For most program especially many of the end of the world if program fails programs. Are not that dependent on the time. Even a lot of the finanical programs. The Date was to just allow the person to get a reference and not much on how the computer did a lot of its processing. Sure there were some spots where it would go 99 to 00 but that was rather rare. Most of the y2k bugs I have seen (and I have seen a fiew after y2k) were just in silly small applications. Like I saw a 1900 in a hotel that had a terminal that displayed the date and time and what was happening today. And still on Milk bottles Ill see expires 1-4-105. For most of those Y2k bugs it was more of a display and user input issue then a rollover issue. During the late 90s I was was doing some fox pro development. And I just had to go to each program and set the year to 4 digit and then stretch the text boxes so it fixed. Fox Pro still internally held the year as 4 digit but just displayed the 2 digits. Besides why would a most people internally handle the year as 2 chars, that fills up 16 bits of storage. If they were using old computers where those bit count they would just use 1 char to store the number and still be able to get to the year 2155 as far in storage and calculations. But people were scared because it was a computer and computers are scary. So they called on all the people they made fun of in highschool to fix the problem.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
How to install a network card driver in Linux:
IIRC, there was an event on Sept. 11, 2001 that all but shut down the U.S. economy for 96 hours. It wasn't software generated, of course, but many of the back up sites, redundant networking and contingency plans that kept the world's largest companies from going into an immediate air-stall owed their existence to the pre-Y2K fervor. Sometimes it takes a little fear to get the suits to pry open the pocketbook.
Of course, now that the current security obsession is terrorism maybe we shouldn't be too surprised by recent software meltdowns..
Working for a facility management company, contracted to a large client in Switzerland, three months prior to the Y2k bitflip. Checked dozens of devices, big and small: embedded controllers for climate control, UPS's, fire alarms, you name it. Found one item: a Compaq PC used for the lighting system had a non-Y2k-compliant BIOS. The result of doing nothing would have been that the weekend lighting profiles for all (several hundred) offices, meeting rooms, and so on would have been active during the week (you know - wrong offset when attempting to calculate whether "today" is a weekend).
/. is the right place for anecdotal evidence, right?)
Replaced computer, had no problems.
Moral of the story: this was a lighting system. Big deal. The client invested several tens of thousands in the project to check three large office buildings in my location, and avoided a minor pain in return. However: everything was checked, and it might have been anything. If it had been the UPS's or the fire alarms for instance, the result of not doing anything could have been a major pain. Point is - we found something, so it wasn't just a waste of time.
(
yes, we have no bananas
The Y2K problem was largely just delayed by clever use of a 100-year window to account for which 2-digit year you're talking about. Once data is required on some system where we need a resolution of 101 or more years, bad stuff will happen. Of course, that's totally separate from a binary representation of "today" being equal to the binary representation of "end of file", but I guess it's easy to lump computer problems all under the same umbrella... and yes, I think the 2038/2029/etc. bugs are going to be a thousand times worse than Y2K, but again, we will come up with a kludge at the last minute that will keep it going for a while longer.
stuff |
The world's infrastructure wasn't, and isn't all hooked up to the internet yet. Fifty or a hundred years down the road, catastrophic failures may happen which we are powerless to stop, because some dickheads thought it was a good idea to have everything interconnected and running the same OS.
Also, the Y2K "crisis" only occurred because humanity as a whole can't seem to plan very far ahead. Or remember its lessons, it seems. The SARS
scare was something that happened a short while ago, and people are already lapsing back to bad habits like coughing with their mouths open in public, in my country.
It seems like most people are too goddamned lazy or apathetic to do the right thing, even if it's for their own good, unless there's threat of immediate pain.
Lastly, look at the tsunami situation. Everybody's going on about tsunami watch this and tsunami watch that, but I can assure you, in five years time, no one will give a shit.
Nobody remembers anything unless the fucking tv tells them to...
It was a hoax! I didn't upgrade my tinfoil and it still works just fine or maybe thats just what they want me to think. *PANIC*
I'm sure anyone who helps support small businesses and their use of IT to run them knows this WAS an averted disaster. Most small companies, in 1999, were using accounting systems (and running them on platforms) that absolutely, positively, would have failed. There were untold thousands of businesses handling shipping, payroll, payables - core stay-in-business stuff - on older versions of FoxPro, or creaky older copies of Unix-based accounting software running on prehistoric Altos machines, and so on.
These would all, everyone of them, puked big time without serious remediation. In many cases it was line-by-line code work, or the building of elaborate insulating layers between modules. In many cases, the cleanest and most rational fix really was a system upgrade. But I can tell you (from having simulated calendar rollovers on such systems), that on 1/1/2000, a lot of my customers (minus the serious work), would have been unable to buy, sell, pay their people, etc., for weeks into 2000 - at which point many would have been mortally wounded. This was no hoax, and the most important work I did at that time was educating the business owners who kept hearing the words "hoax" or "exagerated" on the news.
I wasn't worrying myself about planes falling out of the sky, but I was worried about calamitous damage to a huge chunk of the economy: the $2-15M/year business. Of course, I like to hunt, so no harm buying a little extra freeze-dried food anyway, right?
Don't disappoint your bird dog. Go to the range.
At the time I was a mainframe operator with Penn State (I'm still with them, just in a much less annoying job), and I remember we had a ton of things that needed fixing. Even so, there were some fairly significant problems that popped up on new year's day that had not been caught. If I remember correctly, the program that validated rsa secureIDs failed amoung some other less serious snafus.
:) I know that was a great time for search and rescue teams to pick up cheap gear.
I imagine most places when through something similar, a few years of hunting and fixing and then dealing with some small problems that they missed after the fact.
However, I notice that civilization did not collapse. There was no "fight club" style destruction of everyone's credit rating or a total collapse of the money system, planes did not fall out of the sky, nukes did not sporatically go off, etc. Maybe that COULD have happened but remember people began seriously talking about this problem around 1996 (at least the media began picking it up then) so there was plenty of time to fix stuff.
Many people found great deals on generators and survival gear (food, etc) the following year on ebay
Finkployd
Look at what happened after Y1K - a few hundred years of Dark Ages.
A railroad I know of had to manually route trains for about two to three weeks because of a couple of missed Y2K parameters. Had it not been for a few old-timers who were still around from when that was done a couple of decades ago, all of the predictions about crashes and whatever would have come true for this particular company.
The company covered up the problems in order to protect their stock price. I imagine a few other companies had similar results.
I heard on the radio that in the city where I live, a couple of prison inmates were mistakenly released due to the Y2K bug. At first I thought that was a bogus cover story, but then I remembered that I had worked with the contractor who was supposed to be in charge of the Y2K clean-up at the prison system. He was working multiple projects at that time. Appearently, he could not handle the pressure and he had a nervous breakdown in late 1999. If he did not finish (and I always assumed he did not because he was really falling behind when I was working with him, which of course increased his stress level), I could easily see this story being true.
Any idea why they decided on a signed int? seems like a stupid idea to me. After doubling it to a 64bit int well have 584942417355 years! which brings me to the point.. why didnt they just make it a 64 in the first place, sure most machines wernt 64bit back then, but hey, most wernt even 32bit!
This comment does not represent the views or opinions of the user.
While you're at it, read the whole Wikipedia article, and the transcript of the radio series. Specifically, read the bit about Keynesian economics, and how stimulating aggregate demand can encourage more productive use of capacity where it is underutilized. This arguably happened with the development of low-cost Indian outsourcing services. Second, the radio feature suggests that the trigger of the Y2K issue caused businesses to think about their IT infrastructure and how to improve it in ways that made them more efficient in the long term, more so than they would have done without that pressure.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
Don't worry, a solution to the Y10K problem has already been proposed - RFC 2550 covers it very extensively.
I also worked for a bank in the UK doing admin work on their Y2K project and there was *huge* amounts of planning went into it and a surprising amount of non-compliant systems and software.
./2038test
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
w00t!
LAMENESS FILTER SUCKS...
# Please try to keep posts on topic.
# Try to reply to other people's comments instead of starting new threads.
# Read other people's messages before posting your own to avoid simply duplicating what has already been said.
# Use a clear subject that describes what your message is about.
Facts do not cease to exist because they are ignored. - Aldous Huxley
It's signed because it is necessary to deal with dates before 1970.
What? :-) Look, there's always an April 29th, the leap day being added always to February. And the year 2000 was a leap year, though many thought it so for the wrong reason. The rule is: if year is evenly divisible by 4 if not divisible by 100 unless divisible by 400. Which makes year 2000 a very special leap year as it is indeed divisible by 400.
Stefan Axelsson
"So what's it been like for you this evening?"
One of them turned to observe me. She glared with that particular flavor of ultra-tough female no-monkey-business copitude we have all seen.
"It's going fine, sir. The Y2K Bug is just a myth."
Okidoke, ma'am. Have a happy.
-FL
I've taken on a few systems that have been riddled with hard-coded references to the current year, which invariably means a regular headache every year(alas not from the alcohol) when on New Years Day I find things aren't working the way they should.
It wouldn't surprise me in the slightest if the same thing had happened to HSBC recently, although they obviously wouldn't come out and say it.
Billions of dollars were spent to fix mission critical systems... if they still failed, people would be screaming "We spent billions! Why did we still have the problem?" So instead, they are saying, "We didn't see any problems, should we really have spent the money?"
Maybe I understand Politics a little better after this - it is easier not to spend the money, wait for the disaster, then point fingers.
Why not write this off as a success? Are people just that used to not succeeding?
There WERE various y2k problems... just nothing in major industries like travel, banking, etc.
What about the recent bug mentioned here on slashdot about the airline flight booking system, failing when there were more than 32767 transactions in a given month? That is an example of the same kind of problem the y2k propbem was... I bet the head of Information Technology at that airline was making a 6 figure salary - how could he have the airline so reliant on software that didn't have a backup system, nor one he knew the performance characteristics of?
Think about all the web pages and applications that were displaying the odd five digit year. 11000 I think it was. So I wouldn't say it was a hoax as a whole. There were a lot of opportunistic assholes who saw it as a chance to charge people for upgrades that weren't necessary either though. Not to mention the fear mongers who relied on the natural human tendency to fear the unknown (dried food sales as an example). I will point out that I had a program written in 1993 from the Norton Desktop for Windows 3.1. It was the Norton Dayplanner. I stuck it on a floppy when I got it and carried it with me as a "PDA". I had batch files that I used to sync it with my desktops at home and work. It worked well. Just a few weeks ago I found one of my archival copies of it on CD and ran it under W.I.N.E. Still works, and the dates are correct as well as the year. Interestingly enough, when I ran it in Windows 95, it would skewer the dates past the year 2000. So the app is fine, it was the OS that had the problem. I think in many cases, this was true and it's where a lot of people got taken. They paid for upgrades to apps that relied on the OS for proper date calculation. The main problem is... how do you know this without hindsight? That is how people got taken.
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
I work for a large company. We had a Y2K remediation effort that started about one and a half years out. We had about 60 people on-call across the globe for midnight (great way to spend New Years Eve :/ and had one server outtage near midnight not related to Y2K.
What we did do is leave several servers in different datacenters that were going to be retired unpatched and running. As midnight swept across those datacenters and the patched machines kept running the unpatched ones would fail. Some right at midnight and some a few minutes later. It was a nice verification that all the work we had put in was worth the effort.
-CZ
PS - Yes the unpatched machines ran fine after a reboot. That's not the point of the story.
I can't believe how many people here just don't get it. Nothing happened because of a huge effort, not because it wasn't a real problem. I'd have thought the ./ crowd would have a clue about this.
/. (I just realized how silly that sounds.)
This is the same promlem IT always faces. What we do is abstract enough that management can barely believe we do anything at all, but the fact that you are able to use your computer systems at work doesn't mean that you don't need any IT staff. Come on folks, just 'cause it's working doesn't mean we aren't doing something.
Is your car running? Then I guess you don't need gas, much less oil.
I know I averted a lot of problems for a lot of people. I was doing IT & POS Support, and spent a considerable amount of time dealing with Y2k issues, and my boss spent more time, including dealing with an unfixed Y2k bug in the most popular retail back-end system. But before the year end and after the bios updates & bug fixes, _our_ systems worked. I was on call that night, but I didn't get called. That certainly didn't convince me my Y2k work had been useless. Oh, and dates matter. Talk to anyone doing Sarbanes-Oxley work, or making sales projections, yadda-yadda.
I expect this kind of nincompoopery from the mainstream media, and that's where much of the panic came from. I didn't tell anyone to buy a generator. I expect better of
Assembly is the reverse of disassembly.
Most programs use Coordinated Universal Time (UTC) to work out their dates. Simply, UTC is the number of seconds elapsed since Jan 1 1970.
a ted+Universal+Time
h tm
l _Time
ROFL. That's so utterly incorrect.
Here are some links to the definition of UTC, although I guess the damage has already been done.
http://www.hyperdictionary.com/dictionary/Coordin
http://www.its.bldrdoc.gov/fs-1037/dir-009/_1277.
http://en.wikipedia.org/wiki/Coordinated_Universa
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
However, if we had not done any of that, critical systems would have gone down and we would have lost serious money (millions) on bad trades, fines for failure to settle properly, loss of business from negative publicity, etc.
Yeah, right.
my point was how this was sold to the end users that THEIR computers were flawed
But they were! Especially in the context of my original remarks (smaller businesses running desktop accounting systems, etc), the stuff running on their machines would absolutely have tanked (or worse - seemed to be working, while corrupting data). Most end users (not slash-dotters!) have a very blurry distinction between their hardware, the operating system, the network, the application, and the data. The accounts payable supervisor for a small business will tell you that she "goes to her computer" to pay an invoice, or the shipping clerk will tell you that he "uses his computer" to make UPS shipments.
It was up to us systems people to know how compartmentalized (or not) the problem was in 1999. It was up to good business managers to not engage IT contractors that would defraud them or sell them something they didn't need. Many people hired consultants to police the consultants.
On the home front, there absolutely were people with this problem built-in. Folks using older BIOS versions, two-versions-ago copies of home bean counting software from Intuit, non-patched copies of MS Access, and so on. Would a mis-dated home computer or confused home-consumer desktop app have caused serious financial problems or risk? Probably not as much. Were the problems real? Sure they were, but not for everybody in the same way.
I loathe the scare-tactic opportunists in IT as much as the next guy, but what's even worse are psuedo-pundits that falsely soothe nerves and talk people out of being personally thoughtful about something like Y2K and its direct impact on their situation. For what it's worth, by the way, out of a constellation of about a dozen friends-and-family PCs that I had adopted as tech support charity cases in 1999, probably five or six were spared some inconvenience by things I did for them pre-2000, and two of them were spared major screw-ups in their personal financial records (stock software, etc.). If those people's time is worth anything (I say, it is), then dealing with the problem up front avoided stress, potential fiscal ugliness, and the loss of the value of that time.
I assure you that not one person I interacted with during that period, business or personal, considered the fixes to be hype. Of course, I LONG for those days, when it was something easy to deal with: now those same end users are getting killed with malware that's much more productivity-killing and likely to cause an ill-defined sense of general computing dread. Sigh.
Don't disappoint your bird dog. Go to the range.
The AC is right that temporal logic is hard, calendars are nastily irregular, and there are inevitable errors. As late as 1999 I bought new books with incorrect leap-years examples. Really silly, as unless you need to process birthdates or the like, the % 4 is the correct answer from 1804 to 2096 - more than adequate if you're dealing with the current timestamp.
The vast majority of real-world control systems are embedded systems, not running either mainframe or server or consumer OS -- both good and bad. Various tests of Y2K effects did trigger a few glitches, but the predictions of aircrashes, etc., were always overblown, and mocked at the time.
But! around 1 March 1992 I started to try to get people interested in starting to fix the problems during routine maintainance - too early, no one listened until at least 1998. Similarly, 2038 isn't the only epoch date around - 2036 for those same mainframes is another. In 2009, a number of Y2K "repairs" will need re-patched. Know your epoch!
My logic in 1999 was this: Everything is always breaking anyways and we still seem to get by, why should 1/1/01 be any different? Servers die, applications crash, battery backups fail, power outages happen, cars crash, trains derail, planes wreck, secretaries with "temporary" admin permissions delete entire file servers. From my point of view, I'm amazed that we even make it from one day to the next!
"Yea, but on 1/1/01, it's ALL gonna break at the same time!!!!" Dude, it's already all breaking at the same time. We'll be fine.
And now I get to say: "See, I told you so."
This one gang kept wanting me to join cause I'm pretty good with a bo staff.
Well, having been on-call New Years eve and having handled support calls, here's what I can say...
I was working on ATM software at the time, and we did have two failures. 50% of the banks in the US run our software, so 2 failures isn't very bad. One of these failures was because the bank didn't install an upgraded version, while the other failure was in custom code that had been documented and specced to work only to the very end of 1999, but which both our QA team and the bank involved had forgotten.
Contrary to the doom and gloom that the media was painting about what would happen, these problems didn't interfere with the capability of the ATMs to dispense cash, etc. What it did was simply prevent the computer sytems from automatically notifying someone if the ATM had a problem (like running out of cash).
In both cases, there is a redundant monitor of people sitting in front of a screen, and while the automatic notification wasn't working, the screen was showing that the automatic notification was failing, and so the banks involved could fall back to a manual process of calling in problems.
You don't want to use long long -- use the ISO standard stdtypes.h, and if an implementation doesn't have it, then use one of the applications that can generate it automatically to compensate.
You should never make any assumptions of bit depth of integers in ISO C -- the standard doesn't define them. In the case of this code, on many 64 bit platforms, short is 16, int is 32, long is 64 and long long is 128 -- you almost certainly don't need 128 for this calculation
If your code is acting bloated, and is running rather slow, it's likely and predicted that some loops you will unroll.
There was of course a real second problem in the year 2000 - it had 54 weeks, which tripped up at least one computer system (running a Scandinavian rail system IIRC).
John
This might not be relevant to you, but then, you worked for a company that made a scam as their business principle. Not someone I would buy anything from.
Joachim
People don't write Manifestos any more -- what's going on in this world? [Frank Zappa]
I worked at a major medical center at the time and began asking the IT director to appoint a Y2K coordinator around '96. You can imagine how many systems are running in a shop with tens of thousands of employees.
Well, it was all a "hoax" or "overblown" according to the beancounters until around early 1999, when the press picked up the story for real. Then there was a realization, a sudden panic, and by March of '99 there was a Y2K coordinator in place. The rest of the year was spent in a mad panic to fix/certify the systems. You can imagine how much real work got done during that time.
I imagine this wasn't an isolated incident. Anybody else?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I was on a Y2K team & when we talked to suppliers about Y2K a lot of them refused to accept that 2000 was a leap year.
I ended up getting machine readable copies of Pope Gregory's bull Inter Gravissimus (in Latin) and the 1751 English act of Parliment An Act for Regulating the Commencement of the Year; and for Correcting the Calendar now in Use which adopted it for England. The New Zealand Parliment never having repealed it, it is still law. I'd email these to suppliers, pointing out that they both explicitly said the year 'MM' is a leap year.
Usually they folded at this point. The one really worrying reaction I got back was the supplier of the automated access control system we used on some unattended sites "Well ... it didn't recognise 1996 as a leap year, so I doubt it will recognise 2000"
Yikes!
Where I work (air traffic control) we did extensive testing for two or three years prior to the big event. Most of our major systems were unaffected or easily corrected, although about 20% of the corporate desktops were red-flagged.
We did have one legacy system that we couldn't replace that was known to be a problem. The short-term solution was to roll back the clock to 1972 (the last leap year that started on a Saturday). Everything was fine for about 4 months. Then one day all the flight plans were wrong.
After some investigation it was determined that the shift to daylight savings time in 1972 was on a different weekend than the one in 2000. Normally that wouldnt't be a problem as all aviation-related time and date fields are stored in UTC form. This particular computer, however, was responsible for automatically injecting the scheduled carrier flights into the flight-data system on a daily basis so the airlines wouldn't have to send new flight plans all the time. When the clocks change in the spring and fall, the airlines shift their schedule by one hour UTC so that the 7:00 AM (local) flight still takes off at 7:00 AM. Since this computer thought it was daylight savings time a week or two early, it added one hour to all of the proposed departure times just like it was supposed to do.
We don't normally send flight plans to the computer more than an hour before departure, so the airlines were loading the passengers, closing the doors, and then finding out there was no record of the flight with ATC. The controllers would hand-write the flight data strip and send the aircraft on its way, only to have the computer-generated flight data strip pop out shortly thereafter.
This bug was very easy to fix, but obviously very difficult to predict.