I’ve had a good think about this. Thank you.
Well, there was a bug, or a type of bug. It wasn’t one big bug, the danger was multiple instances of something that sounds quite trivial - representing years with two digits for the date.
So 15th November 1998 would be stored as 15/11/98 or 151198 or 981511,. you get the picture. This was more likely to happen in older code and data, but how much of that was around? Some, for sure, but the only way to know if you had a problem and how big it was was to go looking for it.
One example: Do you remember how years ago PCs used to be sold as “IBM compatible” and it was a good thing to be “IBM compatible”? Well, that original specification that those manufacturers were seeking to comply with was actually silent on two digits of the date as it was to be stored in the bios. It was explicit about having two writable memory locations for the year, so the machine could transition from 90 to 91 to 92 etc. It said nothing about the centennial digits (the 19 in 1993). So there were PCs built that had a proper, rolling, 4 digit year, and others that met the minimum specification and had a hard coded 19. Both were compatible. By the late 90s it is doubtful that anybody was building PCs in that way, but also not impossible that there were still some in the field, or that the BIOS code lingered on in some controller somewhere.
Old code? You betcha. I personally fixed a rather strange piece of code that took the date, extracted the year from the date, reduced that year to 2 digits, then started counting back to 94 (really 1994).
So in December 1999 that code would have counted down
99
98 (IE 99-1)
97 (IE 98 -1)
etc
Until it got to 94. Then it would have exited that loop.
But anytime after midnight on 31 Dec 1999 it would have gone
00
-1 (00 -1)
-2 (-1 -1)
etc
and was not heading towards 94.
This was in a programming language that we knew to not have a Y2k problem, and with a dabase that we knew to not have a Y2k problem, running on a machine with no Y2k bug in the BIOS nor OS. A text book case of old (or just badly designed) code still running on an otherwise non-problematic system.
There were all sorts of manifestations of this (2 digit years) all over the place. So it wasn’t one big bug, it was, as I said, lots of instances of a decision made for various reasons.
It is true that the dire predictions did not come to pass. That doesn’t mean there wasn’t a problem in the first place. We might say that because of the dire predictions and the attendant publicity and, I’d bet, in many cases, legal advice, IT teams made a concerted effort to test and either fix or upgrade. And so in the end it largely didn’t happen (I did hear of small businesses running old DOS applications on old PCs, or with very old cash registers, that had some problems).
Interesting how our minds work. We seem to have gone done a line of thought that only allowed two scenarios
- TEOTWAWKI
- Nothing happened because the whole thing was a hoax.
The third possibility, what I say actually did happen because I was there and I was part of it, that people worked diligently (it was mostly pretty tedious stuff) and fixed their systerms in time, didn’t seem to occur to us.
One example of what went on (in, I’m sure, many organisations). Remember what I said about the grey area in the spec of the original IBM PC. How do you mitigate against that? For a home user you can download a piece of freeware, run that, and then do the necessary. But for a big corporation? We literally tested the BIOS of EVERY intel or AMD based computer in our organisation. (good job we didn’t find any Apples). Seperate tests would be run for things like MS Office version (because early versions did have a Y2k bug). Another team was tasked with identifying smart controllers in the network (say for lifts or air conditioning) and seeking information from manufacturers. A massive effort, repeated many times across the world.
But no good deed goes unpunished.