Part Three of a Five-Part Series
Once in a Millennium: The Year 2000 Problem

Part 3 -- What's the Problem?
by Yi-Hsin Chang (TMF Puck)

This Feature

Part 1
A Problem, Not Armageddon

Part 2
The Source of Y2K Doomsaying

Part 3
What the Y2K Problem Actually Is

Part 4
How Companies Are Working to Fix It

Part 5
The Problem is Y2K Hype, Not Software

Y2K Message Board
Features Archive

Y2K Posts

Read what other Fools are saying about the Y2K problem and post your comments on our board.

What exactly is the Year 2000 problem? For something that has been called a "crisis" and a "time bomb," the Y2K problem is actually a pretty simple one. Back in the Middle Ages of the computer era (the 1970s), memory bytes were expensive and the Year 2000 seemed ages away. To save space, computer programmers used just the last two digits of a year to represent that year, so "1972" became "72" and so forth. But with the approach of the Year 2000, computers operating on the two-digit system simply will not be able to accurately compute calculations based on these dates. For example, in January 2000, a computer at your non-Y2K-compliant credit card company may think your payment is 99 years past due (00 - 99 = - 99) when a payment isn't even due 'til the end of the month.

A lesser-known aspect of the Y2K problem is the fact that the Year 2000 is a leap year. Most people and most computers realize that a year has an extra day -- a February 29 -- if it is divisible by 4 and not divisible by 100. BUT what many computers weren't programmed to know is that a year is a leap year if it's divisible by 400. Systems that don't recognize 2000 as a leap year, as a special case that happens only once every 400 years, will go straight from February 28 to March 1 as usual, setting its calendar off by a day.

An even more obscure problem is more often found in older programming code that uses date fields for special functions. The most common example is 9999, which can mean anything from "save permanently" to "delete data after 30 days." If the date September 9, 1999 (9/9/99) is interpreted as 9999, what may result is unintended chaos. Similarly, in some UNIX applications, 999,999,999 has been used to mark the ends of files, but the same sequence under UNIX also represents the date September 8, 2001. So not only is the Year 2000 a problem for many computers, so are September 9, 1999, and September 8, 2001.

It's actually fairly easy to fix the code at the root of the Y2K problem -- in a single computer. The real dilemma is the scale of applying the antidote to every corrupt piece of hardware, software, and embedded system, though there are far fewer date-dependent transactions out there than the alarmists would have you believe. According to Microsoft's Year 2000 Solutions program manager Jason Matusow, only 5% of the world's computer codes contain dates, though that small number affects 85% to 95% of all other codes.

The doomsayers say that the clock is ticking and there just aren't enough programmers to go around. Not only does this ignore the efforts of many public and private organizations, it also doesn't take into account the very nature of computers. Unlike most other electronic appliances, computers have very short life spans. The stereo CD boombox I bought in 1992 still works and sounds great. But my Apple Classic II purchased that same year, though still adorable and user friendly as a word processor, is essentially useless and therefore lives in my closet because it doesn't have enough RAM (we're talking four megabytes) to even get on the Internet. (A saving grace is that Macs always were programmed to handle the new millennium as well as the next 27,940 years.) And my new Dell computer, like all other Dells shipped after 1996, is Year 2000 compliant.

Many businesses and individuals that haven't already retired old systems will do so as I did in advance of January 1, 2000. In fact, computer makers such as Dell and Compaq are hoping to see demand for new equipment rise as the deadline approaches. Plus, in some cases, a Y2K problem is purely cosmetic and can just be left alone without harming any functions or calculations. In other cases, the codes simply will be corrected. Many software companies have developed tools to find and fix Y2K problems. According to one software firm, a customer was able to repair 100,000 lines of code in a day's time when the task had been expected to take at least 30 days.

Y2K Message Board

Next: Part 4 -- Pilgrim's Progress
Companies are actively working on and making progress on a Y2K fix.
Yi-Hsin explains in part 4.

Other articles by Yi-Hsin Chang (TMF Puck):
-- The Color of Money
-- A Closer Look: Gap Inc.
-- Market of Stocks