Year 2038 Problem

Systems that store Unix time in a signed 32-bit integer can only count up to 2,147,483,647 seconds — 03:14:07 UTC on 19 January 2038. The next second overflows to a negative number, wrapping the clock back to 1901.

Most modern 64-bit systems use a 64-bit time type and are safe for billions of years. The risk remains in legacy 32-bit firmware, embedded devices and old file formats.

At 03:14:07 UTC on 19 January 2038, the number of seconds since the Unix epoch reaches 2,147,483,647, the largest value a signed 32-bit integer can hold. One second later a 32-bit time_t wraps to negative 2,147,483,648, which is read as 13 December 1901, so any software still storing time in 32 bits will suddenly believe it is 1901. Modern operating systems and languages use 64-bit time and are unaffected; the risk is concentrated in old embedded devices, legacy databases, and file formats that fixed the field width.

Most likely not, mainly because the fix is already well understood and largely deployed: 64-bit time_t, which will not overflow for about 292 billion years. Y2K was a data-format problem spread across countless hand-written programs, while the 2038 issue sits in a smaller set of system libraries, file formats, and protocols that have been steadily upgraded since the 2000s. The remaining exposure is in long-lived embedded hardware, such as industrial controllers and older networking gear, that never gets a software update, so the real impact will depend on how much of that is still running in 2038.

Store time in a 64-bit signed integer instead of a 32-bit one, which pushes the overflow to roughly 292 billion years away. In practice that means using 64-bit time_t (the default on 64-bit Linux, macOS, and Windows, and available on 32-bit Linux builds that enable 64-bit time support), widening any database columns, file formats, and network fields that hold a 32-bit timestamp, and auditing code that casts timestamps to int. For hardware that cannot be updated, the realistic options are replacing it before 2038 or isolating it from anything that depends on a correct date.

Most will not, because every mainstream 64-bit operating system already stores time in 64 bits. A device that still uses 32-bit time will not physically stop, but it will jump to 1901, which can break certificate checks, scheduled jobs, logging, and anything that compares dates. The practical concern is old embedded systems and firmware that are still running unpatched in 2038, not desktops, phones, or servers bought this decade.

GPS time itself does not use Unix seconds, so the satellite signal is not affected by the 32-bit overflow, but 2038 is a notable year for GPS for a different reason: the legacy 10-bit week counter rolls over every 1,024 weeks (about 19.6 years), and the next rollover after April 2019 falls in November 2038. A GPS receiver can also be hit by the Unix bug if its own firmware converts GPS time to a 32-bit time_t. Newer signals carry a 13-bit week number, and receivers with updated firmware handle both issues correctly.