Year 2038 solution for embedded Linux (32 bit)? [duplicate]

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