At 03:14:07 UTC on January 19, 2038, a lot of software will try to count one second further and find it can't. Systems that store time as a signed 32-bit number of seconds since 1970 will wrap around to a date in December 1901. This is the Year 2038 problem, sometimes called Y2K38.
Most modern computers are already fixed. But "most" and "modern" are doing a lot of work in that sentence, and some software runs into the limit years before 2038. Here's exactly what overflows, what's still at risk, and how to check your own systems.
Unix time in one paragraph
Unix time counts the seconds since 00:00:00 UTC on January 1, 1970, known as the Unix epoch. Right now it's a 10-digit number a little under 1.8 billion. It's how Unix-like systems, databases, file formats, APIs and log files store moments in time, because a single number is easy to store, compare and do math with. Paste any timestamp into our Unix Timestamp Converter to see it as a date.
Why 2038?
For decades, C and Unix systems stored this count in a type called time_t, which on many systems was a signed 32-bit integer. A signed 32-bit integer can hold values from −2,147,483,648 to 2,147,483,647. Converted to dates:
| Timestamp | Date (UTC) |
|---|---|
| 0 | January 1, 1970, 00:00:00 |
| 1,000,000,000 | September 9, 2001, 01:46:40 |
| 2,000,000,000 | May 18, 2033, 03:33:20 |
| 2,147,483,647 | January 19, 2038, 03:14:07 |
| −2,147,483,648 | December 13, 1901, 20:45:52 |
One second after 2,147,483,647, a signed 32-bit counter overflows. On typical hardware it wraps to the most negative value, −2,147,483,648, which is a moment in 1901. Depending on the software, the result is a date in 1901, a negative time that triggers errors, a crash, or a timer that never fires.
You can try both ends in the timestamp converter, which accepts negative timestamps for dates before 1970.
Why it can hit before 2038
Software doesn't only deal with the current time. Anything that calculates a date in the future can overflow as soon as that future date passes January 19, 2038:
- A 30-year mortgage or bond schedule calculated in 2008 or later
- Certificates, licenses or tokens with long expiration dates
- Warranty, subscription or retention periods measured in decades
- "Never expires" values that someone represented as a date far in the future
From October 14, 2026, there are 4,115 days left until the rollover, which you can confirm with the Days Until Calculator. Any schedule longer than about 11 years already crosses it.
The fix: 64-bit time
The solution is to store time in a 64-bit integer. A signed 64-bit count of seconds runs for about 292 billion years in each direction, far beyond any practical need. Most of the computing world has already switched:
- 64-bit operating systems, including 64-bit Linux, macOS and Windows, use a 64-bit
time_t, so programs built for them are not affected by this particular limit. - 32-bit Linux has needed more work. The GNU C library added a
_TIME_BITSoption in glibc 2.34 that, when set to 64, "changes the width of time_t to 64-bit which allows handling of timestamps beyond 2038," according to the Linux man-pages. Programs have to be rebuilt to use it. - Linux distributions have been rebuilding packages. Debian's 64-bit time_t transition changed the ABI of its 32-bit ARM architectures, armel and armhf. Debian notes that 32-bit i386 was excluded "because its primary use case is running legacy 32-bit binaries," which a change would break.
- JavaScript stores dates as milliseconds in a 64-bit floating-point number, valid to the year 275,760. It was never affected.
So the remaining risk isn't mainstream desktops and servers. It's everything around them.
What's still at risk
Embedded and long-lived devices
Industrial controllers, network gear, cars, medical devices, building systems and other hardware often run 32-bit processors and stay in service for decades. Some built today will still be running in 2038, and their firmware may never be updated.
Data formats and protocols
Even on a 64-bit system, a 32-bit timestamp field in a file format, database column or network protocol still overflows. Upgrading the operating system doesn't change the format of data on disk or on the wire. Any binary format with a 4-byte seconds field needs a new version or a new interpretation.
Databases
MySQL's TIMESTAMP type is a well-known example. Its range, per the MySQL 8.4 manual, is "'1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC." The DATETIME type goes up to the year 9999. On 64-bit platforms, MySQL's FROM_UNIXTIME() and UNIX_TIMESTAMP() functions handle values up to the year 3001, but a TIMESTAMP column itself still stops in 2038. Columns that store Unix time as a 32-bit INT have the same limit in any database.
Old compiled software
32-bit applications that can't be recompiled, often kept running for compatibility, still use 32-bit time.
A related date: NTP in 2036
The Network Time Protocol, which keeps clocks in sync, counts seconds from January 1, 1900 in a 32-bit field. RFC 5905 calls the current cycle "era 0," which ends when the field wraps in 2036, on February 7 at 06:28:16 UTC. The protocol was designed so that correct implementations handle the change of era, but old or simplified clients that assume era 0 could set clocks to 1900. It's another reason to test embedded devices well before 2038.
A similar, later limit applies where software reads a 32-bit timestamp as unsigned: that counter runs until February 7, 2106, at 06:28:15 UTC.
How to check your own systems
- Inventory 32-bit platforms. List devices and servers running 32-bit operating systems or firmware, especially ones expected to stay in service past 2038.
- Look at the data, not just the code. Search database schemas for
TIMESTAMPcolumns and 32-bit integer columns holding epoch seconds. Check binary file formats and protocol messages for 4-byte time fields. - Test with dates after the rollover. Feed your software dates in 2039 or 2040, for example as an expiration date or loan end date, and check what comes back. 2,208,988,800 is midnight UTC on January 1, 2040, which you can verify in the timestamp converter.
- Test the clock itself where you can. On test hardware, set the system time to a few minutes before 03:14:07 UTC on January 19, 2038, and watch what happens to scheduled jobs, logs and certificates.
- Ask vendors. For embedded devices and appliances, ask the manufacturer directly whether firmware is 2038-safe.
New code should store times as 64-bit values or as a date-time type with a wide range, and new IDs that embed time should use a format with room to spare. For example, the 48-bit millisecond timestamp in a UUID version 7, covered in UUID v4 vs v7, lasts until the year 10889.
FAQ
Will my computer stop working in 2038?
Almost certainly not. Current 64-bit operating systems use 64-bit time. The risk is in older 32-bit systems, embedded devices and data formats with 32-bit time fields.
Is this like Y2K?
It's similar in that a date representation runs out of room. The difference is that Y2K was mostly about two-digit years in text and business logic, while the 2038 problem sits in a binary data type used deep inside operating systems, firmware and file formats.
Does it affect phones?
Current smartphones use 64-bit processors and operating systems. Very old 32-bit devices could be affected, but few are likely to still be in use by 2038.
What's the exact moment of the rollover?
The last representable second is 03:14:07 UTC on Tuesday, January 19, 2038. The overflow happens at the next second. In U.S. Eastern time, that's 10:14:07 PM on Monday, January 18.
