Avian’s Blog

Recently I got pointed to this slide deck from Theo de Raadt on moving to a 64-bit type for representing time in OpenBSD. It addresses ways of overcoming the limitation of the way Unix-based systems represent time. Among other things it also mentions the proliferation of the POSIX standard into the domain of embedded systems and the problematic combination of the timer overflow in the not-so-far future and the particularly long life cycles of such systems.

One interesting observation he makes is that applications often do arithmetic on the clock (for instance when calculating timeouts) and that might produce bugs even before the clock itself overflows. So things will probably start breaking well before the January 2038 deadline.

Regarding embedded systems I would like to add that this problem most likely affects a much larger set than those running POSIX-like operating systems.

One reason is that most systems that are programmed in C use the standard C library. While the C standard itself doesn't dictate how time is stored, all of the most common library implementations come from the POSIX world and bring in its definition of time_t as a signed 32-bit counter for the number of seconds from 1 January 1970. For instance, software on VESNA uses newlib. Its clock used to count seconds from 1 January 2012, but that was later changed to the standard POSIX time for the sake of simplicity of using built-in time-handling functions in the C library.

The other reason is that embedded systems often rely on hardware counters to keep the clock. ARM microcontrollers from STM for example have a 32-bit counter in the RTC peripheral. As far as I know it is a true 32-bit counter, meaning it has one more usable digit than the signed 32-bit time_t in POSIX (which adds another 68 years to its lifetime). However, there is no simple way around this limitation in software. You could start using a software counter instead, but that can potentially change response times to other interrupts that might be critical on a microcontroller system. I don't want to even imagine retrofitting that to a system that hasn't been touched in years and might control something big and expensive.

Anyway, for the moment I will go with the prevalent belief that code running on VESNA won't be around for that long and plan to book a holiday in the southern hemisphere for 2038.