Unix time counts seconds since 1 January 1970. Stored in a signed 32-bit integer, it can reach 2,147,483,647 and no further. You can check the date yourself on Linux:
date -u -d @2147483647
On macOS use date -u -r 2147483647. Both print Tuesday 19 January 2038, 03:14:07 UTC. One second later a signed 32-bit counter wraps to a negative number, which software may read as a date in 1901.
This is a known, dated engineering problem with a long fix. It is not a forecast of a collapse, and the date is eleven years away.
What is already fixed
LWN reported in January 2019 that the Linux kernel's core work, led by Arnd Bergmann and Deepa Dinamani, was nearing completion. Kernel timekeeping now uses 64-bit values internally, even on 32-bit systems, and new system calls with 64-bit time were added for user space. LWN also noted that filesystem timestamps and some ioctl() values still needed work at that time.
In 2024 Debian moved its 32-bit release architectures, armhf and armel, to a 64-bit time_t. Its wiki records the key dates: gcc and dpkg changes uploaded on 26 and 27 February 2024, and the transition described as settled by June 2024. The 64-bit architectures amd64, arm64, riscv64 and others already used 64-bit time.
What is not fixed, per Debian's own list
The Debian page is candid about what remains:
- i386 stays on 32-bit
time_tas a compatibility architecture. - NFSv3 uses 32-bit time, and some clients may treat it as unsigned.
- utmp and wtmp timestamps are 32-bit.
- PHP
time()on 32-bit systems will break, though the DateTime API should not. - Some on-disk formats, for example in the inn2 news server, store
time_tdirectly and may need rebuilding.
It also separates two kinds of breakage: build time breakage in 2024, and real wrap-around in 2038. The transition addresses the first, and may fix much of the second.
How to find exposure in your estate
- Inventory 32-bit systems first: embedded devices, older appliances, industrial controllers, point of sale terminals. 64-bit servers are mostly fine, but software on them can still store time in 32 bits.
- Check architecture and time size:
uname -m
getconf LONG_BIT
- Search code for fixed width time fields: 32-bit integer columns holding timestamps, protocol fields, file formats, and C code that casts
time_ttoint. - Test with a faked clock past the limit in a lab, never in production. Tools such as libfaketime can set a date beyond 2038 for a single process.
- Look at long lived data: certificates, contracts, loan schedules and warranties already carry dates beyond 2038 today, and some systems fail well before 2038 for that reason.
What to do now
- Add a Y2038 field to your asset and dependency inventory: architecture, time width, vendor support date.
- Ask vendors of long life devices for a written statement on 64-bit time.
- Prefer 64-bit timestamps in any new schema or protocol.
- Put replacement of 32-bit only devices into normal lifecycle budgets.
Why it matters
Date bugs hide in dependencies. A package list tells you what code you run, and you can then ask which of it touches time. Generating a software bill of materials is the first step.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
When does signed 32-bit Unix time overflow?
At 03:14:07 UTC on 19 January 2038.
Does a 64-bit server guarantee you are safe?
No. Software on it can still store time in 32-bit fields, in databases, files or protocols.
