The millennium bug revisited - Embedded.com

The millennium bug revisited

Editor's note : Colin Walls considers the possibility of a repeat of the “millennium bug” (aka Y2K) panic, when it was thought that timers embedded in systems might not be able to cope with the date roll over to the year 2000.

A decade and a half ago, the software industry in general, and the embedded software industry in particular, were in a state of near panic because much software that controlled critical systems had been designed some years previously and it was feared that it not be able to cope with the date roll-over from 1999 to 2000 – the “millennium bug”. This article looks at the significance of that problem and whether similar problems may arise before 2099.

The Y2K problem
Many of us can remember the near panic about the Millennium Bug or Y2K problem back in the 1990s. The worry was that there would be chaos as soon as the year 2000 dawned because code processing dates would be confused if it stored the year as two digits. The successor to 1999 would thus be interpreted as 1900.

There were many dire predictions: electrical power would fail, planes would fall out of the sky, and the world as we knew it would grind to a halt. As it turned out, it was just an anti-climax. Most people recovered from their hangovers to find that everything was normal. I never heard of any system failing, but I guess the concern was reasonable at the time.

I can think of three reasons why there was not widespread mayhem:

  1. Many systems were fixed in time.
  2. Some systems, that did store the year as two digits had additional logic that inserted a 19 in front only if the value was greater than a particular value (like 70); otherwise a 20 would be used.
  3. Most embedded systems used to control power distribution, planes, etc., do not store dates in this form.

The use of a decimal – or, more precisely, binary coded decimal – representation of numbers was much more common in data processing systems, so banks and other institutions using that system had a much greater need to be concerned. And, where loss of money looks like a possibility, attention tends to be focused. So large armies of COBOL programmers were mobilized to review and fix legacy code. Thus, #1 above applies – many systems may have been fixed in time.

Embedded systems tend to keep date and time information in a binary form, which would not be sensitive to the change of year, so I think that #3 above is a more likely reason for the lack of failures. However, this does not mean that there never will be a problem of this ilk.

Epoch Time
The approach to keeping date and time information as a counter from some specific, arbitrary date is commonly called “Epoch Time”. Using a 32-bit counter and counting seconds gives a span of 136 years, which would serve us well into the future. However, life is never simple.

For reasons that escape me, most systems (including anything based on UNIX) use a signed 32-bit counter, which effectively makes it a 31-bit counter, thus halving its span to 68 years. As UNIX uses an Epoch starting on 1 January 1970, the counter will overflow at 03:14:08 UTC on 19 January 2038. This is only 25 years away! When the overflow occurs, the date will wrap around to 13 December 1901. A website – www.y2038.com – features a counter illustrating progress towards “Doomsday”.

An interesting sidenote is that among certain UNIX communities, it has become fashionable to celebrate significant values of the time counter. The next interesting event is the arrival of the Second Billennium (2,000,000,000 seconds), which will occur at 03:33:20 UTC on 18 May 2033.


Network Time Protocol
A widely used date/time format is thatdeployed by the Internet Network Time Protocol [NTP], which uses 64bits. This consists of two 32-bit fields: seconds and fractionalseconds. Fortunately the seconds field is unsigned, so it has a span of136 years. The theoretical resolution of NTP is 2-32 seconds (233picoseconds), which addresses almost any conceivable application.Unfortunately, the NTP epoch starts on 1 January 1900, which means thatthe rollover will occur in 2036.

Although the choice of epochstart for NTP was a little short-sighted, the documentation for its useaddresses this issue. It suggests that “Implementations shoulddisambiguate NTP time using knowledge of the approximate time from othersources.”

64 bits to the rescue
It is obvious that theproblem of the limited capacity of a 32-bit register can be simplyaddressed by using a 64-bit format instead. Since 64-bit CPUs are nowbeing deployed in embedded designs, this sounds like a sensible wayforward.

Just storing seconds in a 64-bit format provides a spanthat extends to twenty times the estimated age of the Universe. Thatwould be a similar level of overkill to the IPv6 addressing scheme,which accommodates the possibility for the assignment of a unique IPaddress to every particle in the known Universe.

Variousproposals have been put forward for a standard 64-bit time format, someof which have been deployed. Commonly this involves storing eithermilliseconds or microseconds since an epoch, which might be 1 January1970 or 1 January 2000. Any of these would provide a minimum span of300,000 years, which is overkill, but not ridiculous.

We have a quarter of a century to address the 2038 Problem. Over thattime, many systems will become obsolete, as lifetimes of devices getshorter and they are replaced. Fixing the code in systems with “31-bittime” should just be a matter of inserting the keyword unsigned instrategic locations, but I hope the work is performed with a little morecare than that.

I have no idea what systems are likely to fail.By that time, I will be about 80, hopefully retired, and my maininterest may be the integrity of medical instrumentation.

Anyway, we have lots of time to get this fixed – just like we did last time.

Colin Walls has over thirty years experience in the electronics industry, largelydedicated to embedded software. A frequent presenter at conferences andseminars and author of numerous technical articles and two books onembedded software, Colin is an embedded software technologist withMentor Embedded (the Mentor Graphics Embedded Software Division), and isbased in the UK. His regular blog is located at: http://blogs.mentor.com/colinwalls . He may be reached by email at .

3 thoughts on “The millennium bug revisited

  1. Good overview of the issues. I knew about the UNIX problem, but the NTP one was new to me!

    Question: For those systems you mentioned that used only two digits and were “fixed” by taking it to mean “2000 +” rather than “1900 +” if the two existing digits

    Log in to Reply
  2. Yes. You are right. It is only a temporary fix, but it meant that a device might have up to 100 year lifespan [which is overkill] instead of around 20 [which was tight].

    Log in to Reply
  3. FWIW, and sadly that's not much, I believe the original intention of the Unix time was that it should be unsigned and at least 32 bits. However because machine architectures vary and to allow for larger integers, the error value was defined as '-1'.
    That o

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.