Back to the Future with the Millennium Bug

July 18, 2017 Colin Walls

Everyone over 30 or so can remember the “Y2K problem,” also known as the “Millennium bug.” As the end of the century and millennium loomed, there was widespread concern that chaos would ensue. The concern was that any software that stored the date using just two digits for the year, might be thrown into confusion when 99 clocked around to 00. There were expectations of failure at the utilities—power, gas, water, telecoms—along with transportation disruption. In the 1990s, becoming a “Y2K Consultant” was quite lucrative (for a while).

As it turned out, when midnight struck on December 31, 1999, there was not a cataclysm. Whether this was because there never was any problem or because of all the preventative work is unclear. I don’t recall hearing about any failures, but I do remember the level of concern at the time. Although it’s good to consign these events to history, it’s going to happen again and it could be far worse next time.

I was somewhat sceptical in the 1990s—the Y2K bug concerned decimal digits and computers work in binary. Many DP systems would have been programmed in COBOL (a skill that came back into demand in those years), which uses binary-coded decimal, but real-time control systems use binary arithmetic, so wouldn’t be likely to have the problem. I figured that a binary wrap-around might occur sometime and that would be a bigger problem. It looks like I may have been right.

Most systems use a 32-bit counter to track the number of seconds that have passed and compute a date from that. As this gives a capacity of about 136 years, any problems should be well into the future. However, there is the issue of the starting date. Fortunately, this is normally around 1970, which means that problems should not occur until the end of this century. Phew!

However, life is rarely that simple. For reasons that escape me, this counter is commonly a signed variable. Maybe because programmers default to int, which is signed. This reduces the capacity to 68 years, so we can expect trouble in 2038. It’s not clear what systems might fail, but anything based on or related to UNIX may be in trouble.

By that time, I’ll be about 80 and (hopefully) retired. At that time, my main interests may revolve around the integrity of medical instrumentation. Anyway, we have lots of time to get this fixed, right?

Colin Walls is an Embedded Software Technologist at Mentor Graphics’ Embedded Software Division.

Previous Article
Kotlin, a new language for Android
Kotlin, a new language for Android

Kotlin is a newer programming language for Android. It appears to have been adopted by Google.

Next Article
The impacts of early-stage design

Early-stage design decisions have big impacts, especially those that involve layout, material choice, make-...

×

Stay updated on Developer Tools & Operating Systems with the Dev Tools and OS edition of our Embedded Daily newsletter

Subscribed! Look for 1st copy soon.
Error - something went wrong!