Year 2038 solution for embedded Linux (32 bit)?

Question

What is the proper way to handle times in C code for 32-bit embedded Linux (ARMLinux) to ensure that the code continues to work properly after 03:14:07 UTC on 19 January 2038 (when a signed 32-bit time_t overflows)? Given that time_t is signed 32-bit on the system I have to use, what are the alternatives?

A considerable amount of googling has uncovered nothing of practical use. Everyone seems to assume that we will all be using 64-bit OSs by then, but this patently isn't true of embedded systems.

On the system I am required to use, __kernel_time_t is defined as a long. Which presumably means that there is no kernel facility for 64 bit time. The version of uClibc is 0.9.29.

I can't believe I'm the only one with this problem, and I don't want to reinvent the wheel.

Answer 1

There are no silver bullets, tricks or clever solutions. Either use an operating system that has 64 bit time_t or don't use time_t and any OS facilities that depend on it (which includes filesystems, timers, half the network and such) or plan to update the software in the next 20 years.

There are at least two unix-like systems with 64 bit time_t on 32 bit machines: OpenBSD and NetBSD. OpenBSD had a few talks explaining the reasoning behind it: http://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.html

Answer 2

Time conversion routines would "simply" have to use 2038-01-19:03:14:07Z as the base for Unix Epoch time if the timestamp is below a certain value.

I.e. if your system goes productive in 2010-01-01, you can assume that no timestamp, which is not overflown, is below 1262300400 (which is unix epoch time for that date).

If a lower timestamp is encountered, consider that it has overflown and use 2038-01-19:03:14:07Z as base time. Comparisons have to be taken into account, too.

Not a clean solution, but doable with moderate effort. Better switch to 64-bit timestamps (which doesn't absolutely need a 64-bit system, btw).

Answer 3

I assume your embedded system's ABI defines long as 32 bits.

There is no requirement for the time_t type to be signed. Could you possibly make it unsigned long and buy yourself and your descendants an extra 68 years of tranquility? Changing this would require recompiling the kernel, the C library an d all programs and libraries that use time_t... not for the faint of heart! You might as well define it as long long, but this would change many structure layouts and is even more challenging.