Twenty years ago, as the world celebrated the start of a new millennium, IT professionals across the globe were getting cold sweats at the prospect of the Y2K bug kicking in: the fear that important systems relying on two-digit date logs would come to a standstill if computers interpreted the 1 January 2000, registered as 01/01/00, as the first day of the year 1900.
No major incident happened, because developers had seen Y2K coming and prepared well. But two decades later, it has become apparent that some resorted to a quicker fix than others, and simply postponed the problem to 2020.
A series of incidents seem to have confirmed that Y2020 is tech's latest unwelcome blast from the past.
Parking meters across New York, for example, declined credit card payments after an outdated software took the payment option offline in the New Year. The Department of Transportation is still going through the city to manually update the 14,000 parking meters one by one and dubbed the problem a "Y2K2X software glitch".
And a wrestling game produced by 2K, unfortunately named WWE 2K20, reported crashes in the first seconds of the New Year; gamers took to social media to point out that the crash could be fixed by changing the date to the previous day.
Although not officially attributed to a Y2020 bug, failures in Hamburg's subway system hindered traffic after a new year software update proved unsuccessful.
So why are computer systems suddenly struggling with a 20-year-old bug? In some cases it may come down to a technique informally called "the pivot year" and which many a developer used back in 2000 to tackle the Y2K bug.
Say you are an institution founded in 1920. It is safe to assume that you are not sitting on any information dated from before then; and so, in the double-digit date-recording system, "20" becomes your pivot year. This means that data containing a two-digit year between "00-20" will be treated as post-2000, while years between 20-99 will be interpreted as referring to the previous century.
Of course, not all companies and organizations were founded in 1920; but twenty years ago, 2020 seemed far away enough that many developers still chose 20 as their pivot year, assuming that by now most code and legacy systems would be replaced.
Greg Sternberg was a developer and a consultant back then. He worked for finance companies, and told ZDNet that the "pivot year" technique was a quick fix that was frequently used to buy time.
"I was told many times that 'there's no way the program will be running in 2020'. That's true in a lot of cases, but equally a lot of programs stay around longer than initially expected," he said.
"Making short-term decisions might have been the fastest way to do it at the time, and perhaps they were more expedient. But expedient usually means it will catch up with you later."
That's not to say that the majority of organizations picked the pivot year strategy. Another method, which solved the problem in the long-term, was to rewrite all the components of the programming systems, as well as all the databases and data sources, so that they would use four-digit years.
This took time, and a lot of money; between $300bn and $500bn globally, to be precise. It is the reason, however, that there wasn't a complete tech shutdown when clocks struck midnight on 1 January 2000 – to the point that the Y2K bug is often referred to as a scare-mongering myth.
"We didn't wake up to the problem. Some programmers worked on this for years," said Sternberg. "Frankly, they were unsung heroes."
For those who merely postponed the issue for a couple of decades, however, the problems have just started again.