What is the Year 2038 problem?

Unix time is a count of seconds since 1970-01-01T00:00:00Z. The original C type for it, time_t, was a signed 32-bit integer, so it runs from -2147483648 to 2147483647. The top of that range is 2038-01-19T03:14:07Z, 68 years after the epoch. Add one second and the sign bit flips: 2147483648 does not fit, the stored value becomes -2147483648, and that reads as 1901-12-13T20:45:52Z.

Nothing crashes on its own. Timers fire 136 years late or never, certificates that expire after 2038 can fail to validate, and files written after the rollover sort before files from 1970. The bug is already visible wherever software computes a date past 2038 today, such as a 30-year loan schedule or a long-lived certificate. The permalink for 2147483647 shows the last safe second in every zone.

Mainstream desktop and server systems are safe. 64-bit Linux, macOS and Windows use a 64-bit time_t, and 32-bit Linux gained 64-bit time in kernel 5.6, with glibc 2.34 opting in through _TIME_BITS=64. The risk sits in what never gets upgraded. Embedded controllers in cars, meters, routers and industrial equipment run old 32-bit toolchains for decades. File formats and protocols fix the width in their spec: ext2 and ext3 inode timestamps and the cpio archive header carry 32-bit seconds, and many binary wire formats packed a timestamp into four bytes.

Databases have it too. MySQL's TIMESTAMP column stops at 2038-01-19 03:14:07 UTC, while DATETIME runs to the year 9999. Anything that stores epoch seconds in an INT column has the same ceiling.

A signed 64-bit time_t counts to 9223372036854775807 seconds, roughly 292 billion years, so the second-count problem is gone once every layer uses it. The catch is every layer. A 64-bit kernel does not help a 32-bit field in a database schema, a struct packed into a network message or a file format that reserves four bytes. The fix is a migration, not a recompile: find each place a timestamp is stored or transmitted as a 32-bit integer, widen it, then deal with the old data already on disk.

Milliseconds in 64 bits last for hundreds of millions of years. Only nanosecond counts hit a 64-bit limit within reach, on 2262-04-11T23:47:16Z.

The test value is 2147483648, one second past the limit. Feed it to the code path that stores or parses timestamps and check that it comes out as 2038-01-19T03:14:08Z and not as December 1901. On a 32-bit build, date -d @2147483648 or a localtime() call with that value shows the failure directly. Set a test clock past 2038 and run certificate validation, scheduled jobs and anything that sorts by time. The Unix timestamp converter gives you the expected output for any value you try.

A related date arrives first. NTP counts seconds from 1900 in an unsigned 32-bit field, so its first era ends on 2036-02-07T06:28:16Z. Current NTP clients handle the era change as long as their own clock is within 68 years of the truth, which makes a device booting with a dead battery and a 1970 clock the case to watch.