The 2038 Problem

Anyone over the age of, say, 40 will remember the “Y2K problem”. For several years coming up to 2000, we were warned about the terrible consequences of a possible software bug. It seemed that a lot of software would be confused when the year went from “99” to “00”, as it only worked with the last two digits of the year. This sounded credible and many people made a business out of consulting on this matter. COBOL programmers were in high demand to fix old applications. As the Millennium approached, we braced ourselves for stupid utility bills, the lights going out, planes falling out of the sky …

But we were disappointed. There may have been some bugs manifested, but I never heard of one. Maybe all the precautions fixed the problem or maybe is was never there at all [or was quite rare]. My suspicion is that the problem may well have been present in many data processing programs, but these were either dealt with or the problem just did not cause problems. This is because the problem only occurs if the software is dealing with decimal numbers [as may be the case with a COBOL app for example]. Most real time systems [like the software that controls electricity supply, planes etc.] use a binary representation of date, so this issue would not arise.

In any case, it is nice to have this problem behind us. However …

We are sitting on a time bomb. Many systems use a 32-bit counter which represents the number of seconds since the beginning of 1970. That seems fine, as the resulting capacity of this counter is 136 years, which takes us into the 22nd Century. Although my grandchildren may well live to see the next Century, I am not expecting to have that privilege. Anyway, there is nothing to panic about.

At least there would be no reason for concern if the counter were an unsigned value, but apparently it is not [typically]. My guess is that someone made it int or long instead of unsigned or unsigned long. A signed counter would effectively be 31 bits, so the capacity would be reduced to 68 years. To a software engineer in the 1970s and for a long time afterwards, 68 years would sound like plenty of capacity. But now, 2038 does not sound too far off.

There are many kinds of system that might fail: essentially anything based even vaguely on UNIX. I cannot guess what the true scale of the problem may be, but suggest some investigation is undertaken. It would be a shame to have a big rush in 2036/7, bringing all the C programmers out of retirement.

In 2038 I will have my 81st birthday [if I am spared], so I would like to request that any engineers working on medical systems pay particular attention to this issue. Thanks.