My favorite "Myths" about Year 2000

These are a few of the most common things I hear about Y2K that I have found to be simply not true.    These are not counting the really wild stuff that is out there.    See my Gary North quotes for some of that.

Some of this stuff gets a little technical, so if you are not computer literate, you might get bored. Sorry.

"In Great Britain, tons of corned beef was destroyed because of a Y2K bug"

This non-incident occured at Marks & Spencer in England. No corned beef was destroyed at all. What really happened is that a computer was not able to read a date properly, and the data had to be entered manually by a person. Processing of the beef continued as normal.

Thanks to Hank Hanegraaff to exposing this one. See the book recommendation for the details.

"A power plant was performing a Y2K test and the whole plant simply shut down."

There are lots of variations on this one, and I have not yet found any of them to be true. There is one about Hawaii, Great Britian, some unnamed nuclear power plant, etc. When you research these, you will discover that lots of Y2K tests have been performed at power plants, but none of them resulted in power interruptions. In one case, two computer screens went blank, but those computers were just used for data logging. The power continued to be generated. In another incident, the problems were caused by the method of testing, not by a Y2K bug. We have proved over and over by real testing that Y2K bugs do not shut down power plants.

Hank Hanegraaff discusses several of these incidents in The Millennium Bug Debugged.

"In Minnesota, the government sent a 104 year old woman a letter to enroll in kindergarden because of a Y2K bug"

It is true that Mary Bander, age 104, received a letter. But it was not from the government, but rather the St. Stanislaus Kostka Parish of the Catholic school system. Most importantly, the mistake was a human error and had nothing to do with Y2K computer problems! Thanks again to Hank Hanegraaff to exposing this one. See the book recommendation for the details.

Fake anecdotes like this one really irritate me because they tend to bring home the Y2K problem and make it bigger than life. This is a great fear-building story, making people dread the supposed chaos that is coming with Y2K. Only problem is, it isn't real!

"Y2K problem crash computers"

I have yet to see an example of a Y2K error that actually crashes a computer. An actual Y2K computer crash will be very rare.    The operating systems people have fixed their OS Y2K problems - including Windows, Unix, and MVS.    Most Y2K problems - things which make software non-Y2K compliant - cause the incorrect date to be printed on reports and screens.    The more serious problems cause applications to make the wrong decisions, or to report an error and quit.

Instead of "Y2K problems crash computers" A more accurate statement would be "Some Y2K problems cause computer applications to malfunction."

"Every computer/microchip/embedded chip is vulnerable to Y2K failure"

The Y2K failure is only caused by a date dependency in an algorithm.    Even in an embedded chip, there is no vulnerability unless the algorithms (software or firmware) on that chip have a date dependency.    Put simply, unless there is some way you can set the date on a device, it is not going to fail in the year 2000.    Can you set the date on your microwave, copier, air conditioner, elevator, or automobile?   If the device doesn't even know about the date, then it cannot have a date dependency.    If it only knows the date so that it can display it, then only the display has the potential to fail in the year 2000. The Gartner Group estimates that only about 1 in 100,000 embedded chips will be affected.

A computing device must both keep the date and use it in its function before it can even be a candidate for the Y2K bug.    For example, a credit-card swipe machine checks the date on your card before your sale will be approved.    If the expiration date on your card comes before the current date, then you cannot use the card.    These systems therefore are a candidate for the Y2K problem because it uses the date as part of its function.    In fact, they did have the Y2K problem and it surfaced 4 years ago when the first credit cards that expire in 2000 were issued.    That problem has since been fixed.

"No one can know what will happen"

On a global scale, this is true.   The only reason that it is true is that the worldwide system of computing devices is too large to test.    However, we can take components and test them.    We can know whether or not a single computer will work come 2000.    We can know whether a certain application is Y2K compliant.    And we can know about larger systems, such as the data center at a particular company, a power plant, perhaps even a whole city.    Our ability to know is only limited by our testing ability.

A great example of this is the test of the Unit 4 power plant in Fort Lauderdale, documented in Appendix A of my power paper under "FPL progress". One nice thing about computers is that given the same inputs, they will always produce the same results.    Humans don't have this attribute.    Neither do analog systems.    If you test a system today, and you don't modify it, it will work exactly the same way tomorrow.    We can know with confidence that successfully tested systems will work in the year 2000.

"It's already too late to get things fixed"

We still have months to work on the problem.    Now more than ever before, tools are available to work on the problem.    In the Nov. 16, 1998 issue of Information Week, the Bureau of Indian Affairs in New Mexico accurately remediated 1.5 million lines of Cobol code in less than a week using the latest Y2K repair software.    Also, now more than ever, we know more about the Y2K problem.    We have learned which chips, which systems, which software, which controllers have Y2K problems and how they may be fixed.    The most difficult part of the problem, finding the date-dependency bugs, has been completed in many cases.

Companies fall under harsh criticism for not starting soon enough.    But you must understand that 18 months is a generation in computer time.    With the constant flow of new hardware and new software, it would not make sense to implement Y2K fixes on hardware and software that will not be in use by the year 2000.    Once we crossed inside of the 18 month span to the millennium rollover, we saw a huge rise in the Y2K remediation effort, and we are making a lot of progress.

I think we will make more Y2K progress in 1999 than in all previous years combined.

"The railroad switches cannot be manually operated"

This is one of my personal favorites, because it is to easy to prove wrong.    I went and check on this myself. I went to an FEC rail system switch, and there it was - a giant lever used for manual override. I also went over to a CSX rail system switch and found the same thing. Click here to see them for yourself

"The CEO of General Motors said that if Y2K were to happen today that they would not be able to build a car for a year."

The CEO of GM never said this or anything like this. You can read what really happened in the sermon transcript Who's in charge here? - just search for General Motors.

And now, a word from our sponsor ...