The Year 2038 Problem

A signed 32-bit integer tops out at 2,147,483,647. Counted as seconds from the Unix epoch, that is 03:14:07 UTC on Tuesday 19 January 2038. One second later, a system still storing time in a signed 32-bit field wraps around to -2,147,483,648 — which decodes to 20:45:52 UTC on 13 December 1901.

This is the same class of defect as the year 2000 problem, but harder to spot: the limit lives in a binary storage format, not in how dates were typed. Nothing looks wrong until the rollover, and then everything that compares, sorts or schedules by time is wrong at once.

What actually breaks

The failure is not cosmetic. Certificates appear to have expired a century ago, sessions and tokens become invalid, scheduled jobs either fire endlessly or never, file copies decide the destination is older than the source, and databases sort 2038 events before 1902 ones. Anything that computes "how long until X" gets a negative number.

Failures also arrive early. Systems that work with future dates — a 20-year mortgage schedule, a 15-year certificate, a long-lived embedded warranty clock — hit the ceiling as soon as the future date they handle crosses 2038, not in 2038 itself.

What is already fixed

  • Modern 64-bit operating systems: time_t is 64-bit on 64-bit Linux, macOS, Windows and the BSDs. A signed 64-bit count of seconds lasts about 292 billion years.
  • Linux on 32-bit hardware: kernel 5.6 (2020) completed 64-bit time syscalls, and glibc 2.34 lets 32-bit programs opt in with _TIME_BITS=64. Debian 13 rebuilt its 32-bit ARM ports this way.
  • ext4 file systems with 256-byte inodes store timestamps good until the year 2446; XFS gained a similar extension ("bigtime") in kernel 5.10.
  • JavaScript, Python, Java and most managed languages: they already use 64-bit or arbitrary-precision numbers for time and are unaffected at the language level.

Where it still lurks

  • Embedded and IoT devices: routers, cameras, industrial controllers and vehicle ECUs on 32-bit chips with no update path. Devices sold today with 15-year lifetimes will still be running in 2038.
  • MySQL and MariaDB TIMESTAMP columns: the type is defined as 32-bit epoch seconds and ends at exactly 2038-01-19 03:14:07 UTC. DATETIME reaches the year 9999 and is the standard migration target.
  • Old file formats and protocols that serialise a 32-bit timestamp: classic cpio and ar archives, some NFSv3 deployments, legacy financial message formats.
  • Application code that casts time to int or stores epoch seconds in a 32-bit column, even on a 64-bit platform — the platform being fixed does not fix the schema.

How to audit and migrate

The practical test is simple: set a test system’s clock past 19 January 2038, or feed the code a timestamp above 2,147,483,647, and watch what happens. On the storage side, search schemas for 32-bit integer columns holding epoch seconds and for MySQL TIMESTAMP columns; migrate them to 64-bit integers or DATETIME. On the code side, compile 32-bit C with -D_TIME_BITS=64 (and -D_FILE_OFFSET_BITS=64, which it requires), and treat any remaining int cast of a time value as a bug.

For hardware you do not control, the question becomes procurement: ask vendors whether the device stores time in 64 bits, and assume anything embedded and unpatchable that is still deployed will misbehave.

Frequently asked questions

What is the year 2038 problem?

Signed 32-bit Unix timestamps overflow at 03:14:07 UTC on 19 January 2038 and wrap to 13 December 1901. Any system still storing time in a signed 32-bit field will jump 137 years into the past at that moment.

What is the exact date and time of the 2038 rollover?

03:14:07 UTC on Tuesday 19 January 2038 — the moment the count of seconds since 1 January 1970 exceeds 2,147,483,647, the largest signed 32-bit integer.

Are 64-bit systems affected by the 2038 problem?

The platform itself is not: a signed 64-bit second count lasts about 292 billion years. But application schemas and file formats that still serialise 32-bit timestamps are affected even on 64-bit hardware.

Is MySQL affected by 2038?

The TIMESTAMP column type is: it stores 32-bit epoch seconds and ends at 2038-01-19 03:14:07 UTC. Migrating those columns to DATETIME, which reaches the year 9999, or to a 64-bit integer, resolves it.

Will the 2038 problem be fixed in time?

Mainstream operating systems, languages and file systems are already fixed. The residual risk is embedded devices without updates, unmigrated database columns, and old formats that hard-code a 32-bit timestamp.