Recess
Sign in
← Back to feed
You're reading as a guest. Sign in to save posts, see what's new, and tune your feed.
Sign in
TECHNOLOGY · BITE · 2 MIN · INTERMEDIATE

The Bug That Breaks Unix on January 19, 2038

At 03:14:07 UTC on January 19, 2038, 32-bit Unix time overflows. Legacy systems will think the year is 1901.

A 32-bit signed integer can represent values from roughly −2.1 billion to +2.1 billion. Unix time — the timestamp buried at the bottom of countless file systems, databases, network protocols, and embedded controllers — counts seconds elapsed since midnight on January 1, 1970, UTC. In about 68 years, the counter reaches the limit of a 32-bit integer.

At exactly 03:14:07 UTC on January 19, 2038, the next tick rolls the value from 2,147,483,647 to −2,147,483,648. In 32-bit C, that is a signed integer overflow. Systems that read the timestamp will suddenly think the year is 1901.

This is the same class of bug as Y2K: a width that used to be plenty, attached to a counter that keeps advancing. Y2K was fixed because management could be made to care and most at-risk systems were inside banks and enterprises with direct audit pressure. Y2038 is different. Its vulnerable systems are industrial controllers, automobile ECUs, smart meters, and first-generation IoT devices — embedded hardware where the CPU is fixed in silicon and the firmware will never be touched again.

Linux fixed the kernel side in version 5.6, released March 2020: time_t became a 64-bit type, good for about 292 billion years. The GNU C Library followed with time64 support. Most server-class code has already been recompiled. What remains is what you cannot recompile: MRI scanners in hospitals, PLCs on factory floors, fleet-tracking boxes inside trucks, old routers still running 2.6-series kernels.

There are just under 12 years left. That is not a long time in the lifecycle of hospital imaging equipment.

#unix-time#y2038#embedded#linux-kernel#overflow
Sources
WikipediaKernelNewbies