Honey, is it time to go to work already?

Assume for a moment that the predictions of numerous checkout-counter publications do not come true--namely, that the world, the universe, Western Civilization, and (in general) everything that we know and love will not come to a spectacular end; and that the late evening hours of December 1999 dwindle peacefully into the wee hours of the next annum.  

Will you know what day it is? 

Some of us might be honest and admit that there have been past New Year's Days when the aftereffects of the previous night's activities have left us wondering:  not only, "What year is it?" but even "Who am I?," "What happened?," and "Where is everybody?"

Even weeks later, the question may continue to rear its ugly head.   Have you ever found yourself--well into February--still dating checks with the wrong (previous) year? 

Well, all of these concerns keep coming up year after year, but never have they received the attention of the computing-related issue known as the "Y2K Bug."

Will your computer know what year it is?

The short answer is: Yes!    If computers can know this sort of thing, and you assume that a computer knows what year it is right now, then next February the computer will still know it.  This is because what is popularly known as the "Y2K Bug" is not really a bug at all, as with actual software glitches that cause things like crashing a multi-million-dollar satellite into the surface of Mars.   The Y2K Bug is a feature.  It was invented on purpose, and for very good reasons.

A long, long time ago in a land far away, deep in the mists of pre-present-day computer times (about 15 years ago), the PC was not powerful enough to actually do anything except play games with, and real electronic data was actually processed with something called what is today an extremely derogatory term: "mainframe computers."   I know, because I used to program one. It occupied a relatively large amount of space on a raised floor in a temperature- and humidity-controlled room.  It had 3 megabytes of RAM (main memory). That's right--count 'em--three.  Not enough to run Windows 3.1 in protected mode.   However, it did run dozens of sophisticated online transaction processors and a few batch jobs all at the same time on a single processor.  Pretty fast too, I might add.

In those days, there was still a lot of real data (not for backup, it was the actual data) on magnetic tape. Tape is a sequential medium, meaning that in order to update a tape file you have to read in the new version and simultaneously write out the new version of your file, making sure not to omit any of the records you want to keep while leaving out the records you want to delete, adding the records you want to add, and modifying the contents of records that you want to update. The input tape was called "Father," and the output tape was called "Son."   The "Son" quickly grew up to become the "Father" when it was time to do another update of the Master File.

Occasionally, the "Son" would fill up a whole reel of tape and want to spill over to a second one. Now, tapes (and tape drives) were expensive then, and slow. The bigger the data record, the more tape was required. Therefore it became a requirement that we use only the absolutely minimum amount of space in which our data could be contained.

Bits and Bytes

All data--whether in memory, on tape, or on disk, CD-ROM, or in digital storage of any kind--is stored as a series of bits.  A bit is binary-valued; in other words, a bit can only have two states: on or off (ONE or ZERO).   We use combinations of bits to represent things like letters and numbers.  The more bits you use to represent a thing, the more things you can represent in your data.

In computing, the data we commonly deal with contains both words and numbers.  That means we have to represent at least 40 or 50 things:  all the letters of the alphabet, the 10 numeric digits, and a bunch of "special characters."  Using one of two standards, ASCII and EBCDIC, computer makers became able to represent 256 unique characters using 8 bits per character.  Now, every time you store a character you are going to use 8 bits.  Those bits have to be written and read to and from tape, printers, and various other devices throughout the "data processing" life-cycle.

You can imagine, just because of the enormous amount of data we use in this world of ours, how many of those 8-bit characters (called bytes) have to be stored.

It didn't take those of us in the computing profession very long to recognize that we could save a lot of tape, disk, and other resources because of the following set of circumstances:

•   90% of all data is numeric
•   There are only 10 numeric digits
•   You only need four bits to store the values zero (0000) through nine (1001)

And thus was born the concept of a half-byte (packed decimal) representation of a numeric digit. Believe me, those of us who have any sense have stored our numeric data that way almost from the very beginning. And we have saved a lot of time and money in the process.

What is a date, anyhow?

Well, let's see … there are 12 months in a year, 7 days in a week, 30 days hath---nope, that's not worth the space it would take.  Just take for granted that dates all over the world are written down as some combination of numbers. You need to store the year (e.g. 1999), the month (e.g. 10--a nifty way to represent October), and the day (e.g. 12). Now, some people might write this as 10/12/99, others as 99/12/10, some as OCT 12, 1999, and so on. But everybody knows what it means. Everybody with any sense, that is.

Now for reasons that may or may not be obvious by now, many of us in the computing profession decided to store all of our dates using five digits (that's right--just 5 half-bytes!). For example, we would store October 12, 1999 thusly: 99285.   The fact is, each year has only 365 days (366 if it's a leap year), October 12 is the 285^th day of 1999, and it is possible to figure it out! So by using only 20 bits, we can keep track of what day it is!

Wait! You're using 2-digit years!    You need 4-digit years!

At some point within the past decade, a group of people--to whom I will hereinafter refer by using the term "Consultants"--realized that, because they felt they understood how computers stored dates, they could make a lot of money.

Definition:  Consultant (n)--A person who finds out what his/her client wants to hear, tells that to the client, then goes home and sends the client a bill for a lot of money.    [Qualifier: It can be something that the client does not want to hear, as long as it is really, really scary. That makes the client want to hear it.]

Thus was born the idea of the "Y2K Bug."    The Consultants essentially told everyone that they were using far too many "two-digit years" and needed to change them all to "four-digit years," thereby avoiding the "Year 2000 Computer Glitch," a.k.a. the "Y2K Bug."

Some consultants even called them "two-character years" and "four-character years," and sometimes they were sort of accurate in saying that, but more often they were betraying their own ignorance of half-bytes.

Now, the Consultants have made themselves undeservedly rich with this technique.  Not only that, they have spread the wealth.  Their clients rushed out and dragged thousands of retired COBOL programmers out of their condominiums and pressed them into service poring over millions of lines of code at the contract rate of $50 (and up) per hour.

If you don't get anything else out of this, just remember that the money that has been paid to contractors and Consultants doesn't just trickle down to their clients through some magical mechanism of big-business economic genius. It comes directly out of the pockets of mere mortals--like you and me--who pay out our hard-earned money for goods and services.

Now, let's get some facts straight:  We (in the computing profession) admit to having used two-digit years. However, we don't view it as a bug.  As I said at the outset, it's a feature.  It's a feature that has saved businesses untold mounds of money in the form of the hardware and time it would have required to store and process anything bigger than a five-half-byte date untold trillions of times over the half-century since the computer was invented.

But won't the computer think it's the year ZERO?

The straight answer is:  No.

A few milliseconds after midnight, computers throughout your locality will notice that 12/31/99 has passed away and that 01/01/00 has arrived.   Not only that, but they will recognize that it is today, and that today came after yesterday.    How can computers know that, you ask?

Well, the truth of the matter is that computers don't know anything at all (they are binary, remember).  But their operating systems and their application programs were written by real, intelligent people who put a lot of time and thought into making their programs logical, reasonable, and useful.

Programmers also went through a little preliminary training before they sat down and began to code in COBOL.   For example, they went to elementary school and found out what a century is.  A century is a period of time that lasts about a hundred years. That's a long enough period of time to make some intelligent assumptions about dates.

I have a credit card that says--right there on the front--that it is valid through 06/02.  Now, does that mean my card expired in 1902?   I don't think so, and my bank doesn't either.

Suppose you took out a 30-year mortgage 28 years ago.  Does your bank expect your mortgage to last forever?  Or to have been paid off in 1902?    I don't think so. You, your bank, and your bank's computer know when your mortgage period ends.

Suppose you meet someone at lunch and find out that his birth date is 10/12/32. Does that mean it will be another 33 years before this person is born?    Or does it mean that the person is 167 years old? Well, use a little common sense.

Computer programs have stored, retrieved, done calculations with, and sorted trillions of dates over a period of many years.  Logical assumptions have to be made from time to time.  Loans begin now and get repaid in the future.   People you see around you were born in the past.  Today is … well, today is right now, if you know what I mean.

Computers don't make mistakes

Not ever.  However, because they are human, their programmers sometimes do.  Now, the five-digit date, as I have proven, was not a mistake.    But I saw a mistake the other day.

I received in the mail a quarterly statement from a benefit plan whose plan year begins on July 1 each year. The statement warned me that:

Your plan year ends on June 30, 19100.

Ooops!   Now, let's imagine what the programmer was thinking.    Take the century--gotta be 19, right?--and print it out….there.    Then take the year (99) and add 1 to it (result: 100), and print it out … there!   All done!

The sad truth is that the programmer was probably perfectly alright until the Consultants got to him.

The sad truth is that runway lights may wink out; someone may be trapped in an elevator; a cat might get sick; yet another spacecraft may miss its mark.  But these things are no more likely to happen on January 1, 2000 than on any other day of any century, including today.

As for the Consultants:  They believe strongly in providing for their descendants. I won't be around to see it, but I will bet that as early as June 30, 9990 other Consultants--yet unborn--will be telling their clients that they really need to be using five-character years.

Tom Brown is the owner of First Computer Services, as well as an employee of local government.  He specialized in Classical Philology before embarking on a 20-year career in Information Technology, which continues today.