“Y2K” Isn’t over

“Y2K” is over, so there’s nothing to worry about, right?

No, that’s not right.

First of all, calling it “Y2K” was wrong – the problem was a “Date Rollover Problem” that wasn’t specific to the years 1999 or 2000.

It seemed like the year 2000 was going to cause problems, but the explanations given by the popular media were based on a couple of assumptions that just didn’t hold up. The assumptions were: 1) the fixed, or constant part of the date was “1900” and 2) the variable part of the date was going to change from “99” to “00”, sending us back to the year 1900.

What was overlooked was the method that was used to store these items of information.

Information is rarely stored in computers in a way that is easily readable by people. All too often it is stored in a coded form, so that it makes more efficient use of what storage space is available.

So what is the smallest amount of storage space that is required to store the value “1900”? What’s the absolute minimum? In binary, the number is 11101101100, which is eleven binary digits (or ‘bits’). Assigning a minimum of eleven bits to store this part of the information means that this storage area can store a number between 0 (zero) and 2047. There is NOTHING to justify the assumption that the fixed part of the date was “1900”. It could have just as easily been “1950”, “1960”, “2000” or some other value within that available range. All we can validly assume is that (with this scheme) there would have to be at least eleven bits available to store this part of the number, because ten bits only gives a range of 0 to 1023 (and that just doesn’t seem comfortable).

So what is the smallest amount of storage space that is required to store the value “99”? What’s the absolute minimum? In binary, the number is 1100011, which is seven bits. Assigning a minimum of seven bits to store this part of the information means that this storage area can store a number between 0 (zero) and 127. There is NOTHING to justify the assumption that the variable part of the date would become “00”. It could have just as easily become “100”. All we can validly assume is that (with this scheme) there would have to be at least seven bits available to store this part of the number. It’s entirely likely that there would be eight bits allocated to store this information, and that the variable part of the date might go as high as 255 before causing any rollover problem.

If the number “1900” was stored in a human-readable form, the problem gets worse. If it is stored as regular ASCII data, then each of the characters “1”. “9” and “0” require a minimum of 7 bits to store it, for a total of 28 bits for the 4 characters. Bits are usually grouped in eight, so we’re probably looking at 32 bits to store these 4 characters.

So who should care about splitting a year value into two parts? It’s only a few bits, maybe 16, maybe 32, maybe something else. Why should it matter at all?

In the early days of computing, the machines were big, limited and slow. It didn’t seem like it at the time, but we can see that from our current perspective. Memory space was tiny, and having 4028 or 8056 memory locations for a program was typical. Hard disk drives didn’t exist yet, and data was stored on (paper or magnetic) tape or on punched cards.

As an example, I remember reading about one of the largest data processing operations in northern California in 1972. They had a whopping 100 megabytes of data online! Of course by then, the hard disk drive had been invented (they just weren’t storing much yet). Today, as this is being written, you can’t even buy a new 100 megabyte drive anymore – they’re too small!

As the sizes of data files grew (back in the early days of computerdom), it became more and more important to make efficient use of the space that was available. If you could avoid the expense of having to punch a second card by cramming all of the required information onto one card, then you crammed it into one card. If you could make your entire database fit onto two tape transports instead of four, then you did it (because the accounting department frowned on spending the extra thousands of dollars, possibly tens of thousands of dollars for the extra tape machines).

You could embed the fixed part (like “1900”) into your program, where it would only be stored once, and embed a variable part into a data record. Each record wouldn’t need to allocate 16 bits or 32 bits to store the variable part of the year value, but could store half that or less, depending on what scheme you chose. Maybe you could save the company the cost of half a million punched cards per year, if you only stored the variable part of the year with each data record.

Programmers in the early days had to shave things this way. Sometimes it was to save costs, other times it was because there just wasn’t any other way to make it fit into the system.

Assuming that the minimum amount of information allocated to store the variable part of the year value was 8 bits, the potential for the variable part of the year value ranges from 0 (zero) to 255. If we assume that the fixed part of the year’s value is 1900, and add the variable part to that, we get a date rollover problem in the year 2155.

If one of the 8 bits in the variable part of the year’s value is used to indicate a minus sign, the range changes to –127 to 128. Again assuming a fixed value of 1900, this means that the rollover problem can be expected in the year 2028.

These assumptions are only of limited usefulness, for exploring different aspects of the problem. There are other ways of encoding the information as well, and they may or may not have been used by early programmers.

Most folks cannot tell when a date rollover problem will occur. Many talented and experienced programmers cannot tell. It takes a very specialized analyst to determine if a system has a potential problem, and it takes pragmatic testing to see if the problem exists (and to see if the ‘fix’ works!).

The bottom line is: you might see the “Date Rollover Problem” cause some interesting disruptions of service at some point during your lifetime. Then again, you might not. Don’t worry about it, it’s not likely to cause ‘The End Of Civilization As We Know It’.

If you want to ask me questions about this stuff, please feel free to do so.

Other related issues:

The Leap Day/Leap Year problem

The Windows clock rollover

The UNIX clock rollover