Y2K was a two-digit year problem, Y2038 is a 32-bit integer limit, and both are bugs in how software stores time. Y2038 will not hit every system. Modern platforms already use 64-bit time. The exposure sits in old, embedded and rarely updated code, so find that code and test it.
What was Y2K, and why did so little break?
Software of the 1960s to 1990s often stored the year as two digits to save disk and memory. A program facing two-digit years cannot tell 1900 from 2000. Companies predicted large remediation costs, and Wikipedia's summary cites estimates from 400 to 600 billion US dollars before the turn of the millennium.
Few major errors followed. Supporters of the remediation effort argue that this was because many organizations fixed things beforehand. That is a fair reading, and it is also hard to prove, since nobody ran the control experiment. What is documented is that minor problems did appear afterward, for example around 29 February 2000, the first leap year day of the period.
What is the Y2038 problem?
Many Unix-like systems count seconds since 00:00:00 UTC on 1 January 1970 and store the count in a signed 32-bit integer. The largest value that fits is 2,147,483,647. That value corresponds to 03:14:07 UTC on 19 January 2038. One second later the integer overflows and the value turns negative.
This is arithmetic, not a forecast of failure. Whether a given product breaks depends on how it stores and uses time.
Which systems are actually exposed?
The fix already exists in most mainstream software:
- Linux has supported 64-bit time on 32-bit architectures since kernel 5.6, per Wikipedia, mainly for embedded systems.
- The GNU C Library added support for 64-bit time on 32-bit platforms in version 2.34, released in August 2021.
- NetBSD and OpenBSD moved to 64-bit time years ago.
- MySQL's time functions handle 64-bit values from 8.0.28 on supported platforms.
The Linux kernel documentation also records that interfaces returning the old structures were replaced because the seconds field overflows in 2038 on 32-bit architectures.
Exposure remains where updates stop. Wikipedia names legacy and embedded systems as the most vulnerable, along with file systems that use 32-bit inode times, databases with 32-bit time fields, and older 32-bit devices. Recompiling is not always enough either: an application that stores time in its own 32-bit field, or in a file format or network protocol, can fail even on a fixed operating system.
LWN's account of the kernel work adds a useful point. The kernel can provide 64-bit interfaces, but user space has to adopt them, and for many programs that means at least a rebuild.
Are other time rollovers coming?
Overflow is a family, not a single date. Wikipedia notes that a GPS week number rollover falls later in 2038 for a different reason, and that Network Time Protocol version 3 and earlier have a similar rollover in 2036. Treat time as a data type with a limit, and ask where each limit sits in your estate.
Date handling also fails in quieter ways: future dates in contracts, certificates and licenses can hit the limit well before the clock does. Systems that compute dates years ahead can already show the bug.
What to do
- Inventory systems that cannot be easily patched: embedded devices, industrial controllers, older appliances, vendor boxes.
- Ask vendors in writing how their products store time, and for which hardware and firmware versions.
- Search your code and schemas for 32-bit time fields, including database columns, file formats and protocol fields.
- Check build settings for 32-bit targets and confirm which C library and kernel versions ship in your images.
- Test with the system clock set past the limit in a safe lab, including certificate and license expiry paths.
- Add future-date cases to your test suite, such as a 30-year certificate or a long contract term.
- Put device lifetimes on the risk register. A device deployed today may still run in 2038.
- Keep your software bill of materials current so you can see which components ship old time handling.
Quick check
Will every computer fail in January 2038?
No. Systems with 64-bit time are not affected by this limit. The risk concentrates in older, embedded and unpatched systems and in code that stores time in 32-bit fields.
Is a software bill of materials useful for this?
Yes, as an inventory. Knowing which operating system and library versions ship in each product tells you where to ask vendors about time handling. It does not replace testing.
Sources
- Wikipedia, Year 2000 problem
- Wikipedia, Year 2038 problem
- LWN.net, Approaching the kernel year-2038 end game
- Linux kernel documentation, Kernel timekeeping API
Last reviewed: 18 October 2026.
