Will the year 2000 bug cause world chaos?
Dear Straight Dope:
Could you please tell me the reason why the year 2000 will be such a problem for non-compliant computers? I don't get it. Why isn't the year 1987 (or whatever) just as hard for a computer to handle?
Short answer: Computers are stupid.
Longer answer: People can be even dumber than computers.
Real long answer:
Computers are "stupid" because they can only do what they are told. And up till recently, what many of them have been told is to only use the last two digits of the year when getting or storing a date, and "assume" that the century is "19." Other systems treat the year as "years since 1900." Until now this worked fine--1987 was read as "87" in both types of systems. Everything ran (and for now, runs) great. The problem is when the year 2000 rolls around. The first system treats it as "00"--and assumes it means 1900. The second reads it as 100--100 years since 1900.
So what's the big deal? The big deal is that computer systems need accurate dating for many of the tasks they perform. Suppose the Bank of Fred holds the note to your house and the computer keeps track of the loan payments you've made. Like a good guy, you pay on time--the computer reads your last payment date (say 11/30/99) and subtracts that from the date you just paid (12/31/99). Oh look, a month has passed, you're not late. No credit report is made. Now next month: last payment date (12/31/99) subtracted from current payment date (1/31/00) ... hmmm ... 00 minus 99 ... erk!
Depending on how the software is written, the computer may halt on your payment data, or worse, try to process it. What it does with a -99 year span is anyone's guess. Maybe you'll be considered deliquent for 99 years--a dunning credit report is probably automatically generated. Good luck getting that straightened out. Maybe it assumes you've paid in full (you should be so lucky)! In both these cases you might be fortunate (or unfortunate) enough for Fred to notice and step in in time to fix things. But at SuperConglomBank, with millions of creditors and depositors, the likelyhood of timely intervention from human beings is practically nil.
It gets worse. Suppose that it treats the year as "years since 1900." This means that the year 2000 becomes "100." Note that this is more than two digits. Databases where data is stored have "slots" for each bit of data--in all probablility, the slot for "year" only holds two digits. Which ones get stored, and what happens to the extra? Maybe it gets lopped off the end. Maybe it gets stored in the adjacent slot, overwriting whatever was stored there--hope it wasn't important, like your Social Security number. Plus, data is exchanged back and forth every second in this society. Maybe this damaged database is shared with the credit bureaus. Unless it's detected, their data goes bad. And they share with XYZ Inc. And so on.
And this is just a microscopic sample of what can go wrong. This bug can affect millions of systems: personal PCs, networks, mainframes, embedded systems (preprogrammed specific hardware like pumping station controllers, utility generation controllers, etc.). It can impact every aspect of your life: banking, utilities, transportation (commercial especially), government services (yes, the IRS as well--about the only bright spot in this whole mess). It can hit you directly (your job, your bank account) or indirectly (stores have shortages, your ATM won't work due to telcom problems, local nuke plant shuts down). No one is immune.
So why did this happen? Well, people are dumb sometimes. In some cases the year wasn't properly programmed to save space on old systems, where every byte was expensive and precious. These old systems were never replaced, just added onto and patched over the years--after all, if ain't broke... In other cases people programmed that way because ... well, just because. Think about it--when you write the date do you write the whole year, or just the last two digits? You don't have to have been born yesterday (7/5/98) to figure that out. Even where problems were recognized well ahead of time, there was never enough money or time to fix things--"there'll be plenty of time next year" or "we can't budget for that," etc. Typical management puffery, but you can't blame a guy who probably won't be there in six months, can you?
But now that we recognize the problem, we can fix it, right? Well, um, no. Not enough time. It's not a question of money anymore (though billions--that's billions with a "B"--are or will be spent in the next 18 months. Or maybe it's trillions with a "T," I forget). Many large systems, especially government systems, are too far behind to fix everything, and throwing more programmers at the problem won't work (especially outsiders who wouldn't understand the often-massively customized mainframe-type systems). Some systems (embedded in particular) can't be fixed--they have to be replaced (FAA's, to name one). And first you have to FIND the embedded system--not an easy task. It's not all that simple finding the problems in software systems either (ever seen date variables named after the programmers girlfriend or dog?). And while the actual software fix may be relatively easy, there can be hundreds of fixes to do--in a million line program. Without documentation. And missing source code. (Uphill, in the snow, before dawn ... Dad? Is that you?)
So now it's triage. The plan is to try and fix critical systems and ignore anything else (those with cosmetic problems, or ones that have problems sorting files, etc.). Smart people and companies have contingency plans--how can we continue to operate if X system crashes? What if supplier Y can't deliver for a month (think of the GM strike folks--it's not a minor problem)? Stupid or desperate ones are ignoring the problem and hoping it goes away.
I don't know what will happen--I'm not Cecil, and he ain't telling. And the programmers don't know either. Nobody knows. Look at embedded systems. For the most part, they don't use dates (why would your toaster care what year it is?). And most of those won't be affected by the year 2000. But there are billions (again, with a "B") of embedded systems out there. Even if it's 1% of 1%, we're still talking thousands to millions of problem systems. How many of those are in VCRs, versus oil platforms or nuke plants? How many shut things down, versus messing up the date on a report? Who knows? It's an unprecedented problem. It could be a fizzle, or it could mean the end of western society. It's probably somewhere in between, of course. But many of those closest to the problem--programmers--started a Usenet newsgroup called comp.software.year-2000. It went from discussions of fixing systems and hiring rates to storing wheat and survival gardening ('bout half the threads are crossposted to misc.survivalism these days). But hey, it's Usenet, take it with a grain of salt ("ooh, iodized salt--store it, especially if you live inland...").
One last thing--it isn't "hype" like some have claimed. Oh, there are companies making a buck off of it, sure. But real money has been put down by real corporations like GM and AT&T. The government recently set up a $4 billion (there's that "B" again) emergency spending fund. Hey, even for Congress that ain't all that cheap. Real problems have been noted in testing systems. Economists are predicting chances of severe recessions due to the bug. Read the newsgroup "comp.software.year-2000" for a while (set crap-filter to high, of course). Ed Yourdon (one of the Big Names in software engineering) wrote a book with his daughter Jennifer, Time Bomb 2000, describing various scenarios and how to deal with them. Mainstream media is also catching up to the problem, and more information than you need will soon be rolling out of the presses.
I'm not telling you to panic--it's not my job, and you shouldn't listen to me anyway. You have to decide for yourself how important this is. Do you ignore it and party down on New Year's Eve 1999, or do you stay home and practice trapping squirrels in your backyard? It's up to you.
But, just in case, here's a hint--it tastes like chicken.