The Year 2038 problem affects systems that store Unix time as a signed 32-bit integer. That counter can hold seconds only up to 03:14:07 UTC on 19 January 2038. One second later it wraps to a large negative number, which software reads as a date in December 1901.
The mechanism
Unix time counts seconds since 1 January 1970 UTC. A signed 32-bit integer tops out at 2,147,483,647. The next value wraps to the most negative integer, which equals 20:45:52 UTC on 13 December 1901. Code that compares dates, schedules expiry or computes durations then misbehaves.
What can be affected
Wikipedia's summary lists examples: file systems that store 32-bit times in inodes, such as ext2 and ext3, databases with 32-bit time fields, older Android versions, some 32-bit iOS devices, and embedded systems, which it calls the most at risk because they are rarely updated. Software compiled with 32-bit time functions is also exposed.
Note that dates before 2038 can fail too. Anything that handles a future date, such as a 20 year certificate or a long contract expiry, can hit the limit early.
Known fixes
There is no single fix. Switching to unsigned 32-bit only moves the limit to 2106 and breaks dates before 1970. The usual remedy is a 64-bit time type.
- Most 64-bit operating systems already use a 64-bit time type.
- Linux 5.6 added support for 64-bit time on 32-bit architectures, mainly for embedded use.
- glibc 2.34 supports 64-bit time on 32-bit platforms when the build option for 64-bit time is set.
- Some filesystems have extended timestamps: ext4 with larger inodes reaches 2446, and XFS with big timestamps reaches 2486.
A checklist for your code
- Search for
time_t, 32-bit integer timestamp fields andintused for epoch seconds. - Check database columns and the engine versions that store timestamps.
- Test by setting a test clock to dates after January 2038, including file times and token expiry.
- List embedded and 32-bit devices, and ask each vendor about their plan.
- Check binary file formats and protocols that carry a 32-bit time field.
For a hardware focus, see Year 2038 versus Y2K: an embedded device checklist.
Where the bug hides in real code
The classic pattern is a database column or struct field holding epoch seconds in a 32-bit integer. It also appears in file formats that define a four-byte time field, in network protocols, and in embedded code that casts a larger time value down to fit. Reading code for the type is not enough, because a 64-bit time can still be truncated when it is written to a 32-bit field or passed to an old library.
A good test is to push dates past the limit through every boundary: storage, serialization, API calls and display. Failures at those boundaries are exactly where a hidden 32-bit conversion shows itself.
Quick check
Do modern 64-bit systems have this problem?
Mostly not, since most use a 64-bit time type. Legacy software, binary formats, databases and embedded devices can still be affected.
Sources
Last reviewed: 19 October 2026.
