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.
Make Recess yours.
Sign in to save the ones you loved, never see the same thing twice, and tell us what you want more of.