The millennium bug revisited

January 29, 2013

Colin Walls-January 29, 2013

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 – – 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.

< Previous
Page 1 of 2
Next >

Loading comments...