Back at the beginning of January there were reports of faulty computer systems apparently caused by the year being 2020 (including the video game W2E 2K20), a variation of the Year 2000 bug. Is it and why?

Well, buckle up, as this is a long one. But, as both one of those people who was tasked to stop the Y2K bug back in the 1990s but also one of those people who was the cause of it in the first place, I feel I’m in a good position to comment further…

What was the Year 2000 bug?

Due to small and expensive computer memory and storage in past decades (although we’re mainly talking pre 1980s), data was held in as small a space as possible. And dates was one such item of data that could be shrunk – by not storing the century, a year could be just 2 digits (e.g. 71 instead of 1971). This was great because nobody thought these basic pieces of software would still be running at a time when the century mattered.

What nobody accounted for was the slow pace of change in big businesses – banks in particular. They built large, complex systems which, despite their creaking age, nobody wanted to re-write. So as the year 2000 approached, these shortened years were suddenly a concern.

Why? Well, it comes to down to when you do comparisons. Let’s say you have data for 1971 and 2002. Which came before which? Obviously, 1971 comes before 2002. But when you now say which came first out of 71 and 02… a computer will say 02.

What was likely to happen was that as the clock ticked over to 2000, lots of computer systems will see it as the equivalent of 1900 and stop processing correctly (and if you think about banks, this could means debits not being taken, cheques not being cashed, etc).

There was also a lot of noise around “embedded systems” where items such as washing machines would suddenly stop working – many devices have timer chips built in. However, I always felt that this was probably bogus, as although they may time things, they don’t do any kind of date comparison – sure enough, this turned out to be a giant red herring.

Why did everyone panic?

Because there was genuine cause to. If nothing had been done, software and, potentially, hardware around the world might have done some unexpected things – particularly around money, which have caused major economic problems.

However, the panic around embedded chips didn’t really help because, as I say, that turned out to be quite an exaggerated issue in the end.

What was the fix?

It wasn’t what you’d expect, which is to add centuries to these stored years.

What you have to remember is that expanding the size of a file to include the century is not as simple as you’d think – every program that accesses that file has to be re-compiled, unit and system tested. Y2K was a huge undertaking already but to do that would have made it many times bigger. So, the solution was not to change the file but any programs that did date comparison – that reduced down the amount of code and programs changed, and reduced costs.

So, for example, if we use the previous example of 1971 and 2002. They would still be stored as 71 and 02 but, instead, code may make a decision as to which century it was based on year. Let’s say that in this example there are no dates before 1970 – in this case, you’d change the code so that a date less than 70 would have ’20’ appended to it, otherwise ’19’. Only then would you compare the dates and, in this, case, it would now work correctly.

But, nothing happened when the Year 2000 came

This is oft quoted, and Y2K is now seen by many as something blown out of all proportions because “nothing happened”.

In reality, it’s estimated that over $300 billion was spent fixing it (and, as we’ve seen, the work was done “on the cheap” as it is). This is an example of a potential disaster being diverted successfully.

As I’ve said, I was one such person tasked with making a lot of the fixes for a large retailers. Indeed, as the clocks struck midnight on December 31st 1999, I was sat in the office all night, monitoring all the mainframe software as it ran. Even after all the work, there was still some minor issues.

So, why is there a Year 2020 problem?

This seems unrelated to the Y2K bug. For example, the New York parking meters stopped working because they’d intentionally added in an “established end date” that had been forgotten about. The faulty W2E 2K20 video game has been fixed but no details have been released as to what happens. However, I suspect it’s all totally unrelated and these are just random date related issues. It’s probably not coincidence that 2020 when stored on a computer is the same as 2 spaces (a space in ASCII is 32, or 20 in hex)

So, the Y2K Bug won’t re-occur?

You remember that code method of getting around it? In my example, it would only work correctly until 2069. When it gets to 2070, it will see the year less than 71, so append a 19 to it and it becomes to 1970. Just as the original developers didn’t imagine the year 2000 being reached, those working on the Y2K bug did the same thing and were blinkered to those programs still potentially hitting any other limit.

But what’s different here is that developers used different limits. So, it my example, all will work until 2069 – if that code is still in use after this date, we’ll see issues re-occurring. But other people will have used different ranges, depending on how far back they needed their earliest date to go and it’s perfectly possible that we’ll start seeing occurrences soon.

Wait – why did you allow this?

I can’t speak for everyone, but as a mainframe developer in the 90s, I wrote was I was told and, the range of what we could do was limited by budgets.

And, as I said before, many people thought that those programs wouldn’t still be running when the new limits hit. Some voices thought otherwise, and I was one of them. Put it this way, at the company I worked for, 30 years later many of those programs are still running.