Preface. I am a systems analyst at an insurance company (which one doesn't matter and I'd rather not say; these are my opinions and not theirs). Since the spring of 1997 my entire job has been the Year 2000 problem: finding it in our programs, fixing it, testing the fix, and planning for what we missed. I have read more thirty-year-old COBOL than any healthy person should. I also have neighbors who have asked me, at the mailbox, whether they should buy a generator, and coworkers' relatives who have bought a year of freeze-dried food, and a brother-in-law who is convinced the banks will fail. This page is what I tell them. It is neither "nothing will happen" nor "the end of the world." It is what the problem actually is, what has actually been done about it, and what a sensible household should actually do, which is not very much.

For most of the history of computing, storage was expensive. A punched card held 80 characters, memory cost real money per byte, and a data file with a few million records in it was cheaper to keep if every record was a little shorter. So programmers, quite reasonably, stored the year as two digits. 1965 became 65. The "19" was understood. Everybody knew it, nobody wrote it down, and the programs written in 1968 were not expected to be running in 1999. A good many of them are.

The problem is arithmetic. A program that computes your age, the interest on a loan, whether a policy has expired, how many days until a bill is late, or which of two records is newer, does it by subtracting dates. If "this year" is 00 and your policy was issued in 97, then 00 minus 97 is negative 97, and the program does something with that number. Maybe it decides the policy is 97 years old and cancels it. Maybe it decides the policy hasn't been issued yet. Maybe it sorts your 2000 records before your 1980 ones. Maybe it divides by the result and stops. Maybe nothing happens because that particular field is only ever printed and never calculated. Every case is different, which is why this took a lot of people a long time.

That is the whole bug. There is no virus, no conspiracy and no mystery. It is a storage shortcut that made sense at the time, multiplied by a few billion lines of code.

The programs that run the financial guts of banks, insurers, utilities, governments and big manufacturers are mostly not new. They are COBOL programs on large IBM-style mainframes, written in the '60s, '70s and '80s, patched every year since, and never replaced because they work. A company like mine has several million lines of this. In COBOL you describe every field explicitly, so a year field looks like PIC 99 (two digits) in a record layout that has been copied into hundreds of programs. Every one of those programs, and every file and every report and every screen that touches that field, has to be found and looked at.

There are two standard ways to fix a field once you've found it:

• Expansion. Make the field four digits. Correct, permanent, and expensive, because you have to change every file that holds the record and every program that reads it, and convert all the historical data, all at the same time.
• Windowing. Leave the field two digits and teach the program a rule: years 00 through (say) 29 mean 2000-2029, years 30 through 99 mean 1930-1999. Cheap, quick, and it works for as long as your data doesn't span more than a hundred years. Most fixes done in the last two years are windowing, and yes, somebody in 2029 will have a smaller version of this job. They'll have better tools.

The mainframe work is the big, slow, well-understood part. The part that got the headlines this year was "embedded systems": the little chips inside elevators, building thermostats, phone switches, medical equipment, factory controllers. Most of those don't know or care what year it is. Some do. Everyone in my line of work spent 1998 sending letters to the manufacturers of every piece of equipment in the building asking whether it does, and the honest answer for the large majority was "no, it doesn't track the date at all."

A great deal. This is the part the scarier books and Web sites leave out, because it is not exciting. Between 1996 and now, the large organizations that could be seriously hurt by this — banks, the Federal Reserve system, the stock exchanges, the big insurers, the electric utilities, the phone companies, the airlines and air traffic control, Social Security (which started on this in 1989, earlier than almost anyone), the IRS, the big states — have spent an enormous amount of money and staff time finding and fixing date logic and then testing it. Estimates of the total bill run to the hundreds of billions of dollars worldwide, and roughly a hundred billion in this country. That money bought something.

The bank regulators have examined every bank in the country on this, more than once. The utilities have reported their readiness to their industry council and to the government. The federal government's own count of its mission-critical systems has been in the high nineties percent "done and tested" for months. Where I work, the last of the core policy systems was signed off in June, and since then we have been on to the leftovers, the vendor packages, and the contingency plans.

What has not been fixed as thoroughly, and where I'd expect the actual problems: small businesses that assumed it didn't apply to them; old PC software in doctors' and dentists' offices; some local governments; and a number of other countries that started late. None of that is the electric grid.

My honest professional expectation, for what it's worth, is this:

• The lights stay on, the phones work, the ATMs work, the planes fly. The people who run those things have been testing for two years and have people sitting in the room on New Year's Eve.
• There will be glitches, and you will read about every one of them. A billing system somewhere will print an invoice dated 1900. A store's cash register will refuse a credit card whose expiration reads 00. A county's Web site will show the wrong date. A video store's computer will charge someone a hundred years of late fees, and it will be on the news, and it will be fixed by Tuesday. Some of these will be genuine Y2K bugs and some will be the ordinary Monday-morning failures that happen every week and never make the paper. In January, everything that breaks will be blamed on Y2K.
• Some things will break in a way that takes weeks to notice, because they only run at month-end or quarter-end. February and April will have their own small surprises. This is normal.
• The most likely real disruption is people, not computers. If a lot of people withdraw a lot of cash the same week, or fill every gas can in the county on the same afternoon, that causes exactly the shortage they were afraid of. The Federal Reserve has printed extra currency for the year-end so that the banks won't run short if people do want more cash in their pockets. The best thing an individual can do for the country's Y2K readiness is to not panic.

I could be wrong. Nobody has ever done this before. But I have seen the inside of the effort, and the inside is much less frightening than the outside.

Prepare for the year 2000 the way you'd prepare for a bad winter storm or a three-day power outage, because that's the worst plausible case for a household, and because those preparations are worth having anyway. The Red Cross has put out a checklist along exactly these lines, and it is sensible.

• A few days of food and water that doesn't need cooking. Not a year. A few days. Canned goods, crackers, peanut butter, a gallon of water per person per day. Rotate it into the pantry afterward.
• Flashlights, batteries, a battery radio, blankets. It's January.
• Some cash — enough for a few days of groceries and gas, in small bills, in case a card reader somewhere is confused. Not your savings. Your money in the bank is insured by the FDIC up to $100,000 per depositor, and the bank has been examined on this by people who do it for a living. Cash under a mattress is not insured against anything. Please do not withdraw it all; that is the one way the banks actually could have a bad week.
• Paper copies. Your last few bank and credit card statements, your mortgage or loan statement, your insurance policy numbers, your pay stubs, your investment statements, and your December receipts. If a computer somewhere gets your balance wrong, paper is how you prove it. You should have these in a folder anyway.
• A full gas tank on New Year's Eve, which costs nothing extra.
• Prescriptions filled before the holiday, which you'd do anyway over a long weekend.
• Know how to open your garage door by hand. That's a power-outage tip, not a Y2K tip, but people ask.

What we are not doing: buying a generator, buying a gun, buying gold, moving to the country, or stockpiling anything we wouldn't eat in a normal month. If you have already bought the generator, it will be nice to have in an ice storm.

Two weeks ago was 9/9/99. For years there has been a worry that programmers in the old days used a field of all nines — 9999 — to mean "end of file" or "no expiration" or "delete this record," and that a program encountering a real date of 9/9/99 might mistake it for the marker. It is true that this was done sometimes. It was also always a lot less likely to bite than the century rollover, because a date field of 9/9/99 is six digits (090999), not four nines, and because anyone who used the nines trick generally used it in a way that a real date couldn't match. We tested for it anyway, along with everything else. September 9 came and went and, as far as I have heard from anyone in the field, essentially nothing happened.

Something similar had already happened in August: the Global Positioning System's satellites count weeks in a ten-bit number that rolled over to zero on the night of August 21-22, and there were predictions that receivers would go haywire. A few old ones did need a reset. Ships did not run aground. And when the fiscal year 2000 began on July 1 for most of the states, and on October 1 for the federal government, their budget systems had to handle year-2000 dates, and largely did.

I mention these not to say "see, nothing ever happens" — January 1 is a much bigger test than any of these — but to say that the pattern so far is: the systems that were worked on, worked.

Here is the one the general public mostly hasn't heard about. The rule for leap years is: every year divisible by 4 is a leap year, except years divisible by 100, which are not, except years divisible by 400, which are. 1900 was not a leap year. 2000 is. A programmer who remembered the first exception and forgot the second wrote a program that thinks February 2000 has 28 days, and on February 29 that program will either reject the date as impossible or silently treat it as March 1, and every day after that will be off by one until the end of the year. December 31, 2000 is day 366 of the year, and a program that only allows 365 days will have its own opinion about that.

This one is easier to test for and we have. But it's a good example of the kind of small, dumb, entirely human mistake this whole subject is made of. It's never the computer. It's someone in 1978 who was in a hurry.

Short version: a PC bought in the last two years running Windows 98 is almost certainly fine, and if it isn't, the worst case is that the clock is wrong and you set it. Longer version:

• Every PC has a little battery-backed clock chip. On some older machines (mostly before about 1997) that chip stores a two-digit year and the computer's start-up software (the BIOS) doesn't correct it, so when the clock ticks past 11:59 p.m. on December 31 it may come up saying 1900, or 1980, or 1994. The fix is to set the date. Windows and most software then keep it correctly. That's it. If you want to know in advance, back up your files, then set the clock to December 31, 1999, 11:58 p.m., turn the machine off, wait five minutes, turn it on and look. Then set the real date back. Do this while the computer is not connected to anything, and don't do it if you have software with a time-limited license that might notice.
• Windows 98 itself has had a year-2000 update available through Windows Update since this spring. Run Windows Update and take what it offers.
• Applications: check any program that deals with dates — your checkbook program, your tax software, a database you built yourself. Look on the software company's Web site for a "Year 2000" page; every one of them has one now. Spreadsheets deserve a special look if you typed years as two digits into a formula somewhere.
• Your files — the letters, the photos, the school papers — are not affected by any of this. A document doesn't know what year it is. Back them up anyway, because you should.
• Your VCR, microwave and coffee maker do not know what year it is either, whatever you have heard. A VCR with a year setting in its timer might refuse 2000; if so, tell it the year is 1972, whose calendar is identical to 2000's (a leap year starting on a Saturday), and it will record your programs on the right days.

For the curious. The project went in phases, which everyone in the industry ran more or less the same way:

1. Inventory (1997). List every program, file, screen, report, vendor package, PC application, and piece of equipment with a plug. Ours ran to thousands of items. The inventory alone took most of a year, partly because nobody had ever made one.
2. Assessment. Run scanning tools over the code to find every field and variable that looks like a date, and then have a human look at each one, because the tools find things called WS-DATE easily and things called WS-TEMP-2 not at all. Decide, system by system, expand or window.
3. Remediation (1998). Change the code. Thousands of programs. Some by tools, most by people, some by contractors we'll never see again.
4. Testing (1998-1999). The long part. We set up a separate copy of the mainframe environment with its clock set forward, ran a whole month of business as if it were January 2000, then February 2000 (including the 29th), then December 2000, and compared every report to the same month run with today's date. Every difference gets explained or fixed. Then you do it again.
5. Contingency planning (1999). Assume something we didn't find breaks. Which systems matter most? What's the manual procedure? Who is on call? Paper forms have been printed. A room with phones and coffee has been reserved. I will be in it from 8 p.m. on December 31 until sometime on January 3, and my wife has been very understanding.

Then, in the spring, I expect to go back to doing whatever I did before, which I've almost forgotten. There's a rumor about a project involving the Internet.

Elsewhere on GeoCities.us: Learning Perl the Hard Way (a sysadmin who found his own two-digit-year bug, see his section 2) · Mom's Guide to the Family Computer · Brian's PC Help Page · Ham Radio Shack (the emergency-communications volunteers are ready, too) · Where Thinking Machines Are Going: A Look at 2026 (for after we get past 2000) · SiliconValley neighborhood

Visitors since July 4, 1999:  

Questions and corrections: [email protected]
I'll answer what I can. I will not tell you which company I work for, and I will not tell you to buy a generator.

Last updated September 23, 1999. © 1999 Gordon Hale. Opinions are mine alone and not my employer's. Nothing here is financial or legal advice; it's one practitioner's honest read of the situation as of the date above. This page will be updated in January with what actually happened, whatever that is.