The Unix Year 2038 Problem

Updated: May 2026

The Year 2038 problem is the digital equivalent of Y2K — a structural limitation in how older systems store time that will cause failures on a specific date. Unlike Y2K, the cause is well understood, the date is precisely known, and the fix is straightforward: switch to 64-bit timestamps. The question is whether every affected system will be patched in time.

Convert any timestamp →

Free · No upload · Instant

The exact moment it happens

2 147 483 647

January 19, 2038 — 03:14:07 UTC — the maximum value of a signed 32-bit integer

At this moment, any system storing Unix timestamps in a signed 32-bit integer (int32_t) will overflow. The integer wraps from the maximum positive value (+2 147 483 647) to the minimum negative value (−2 147 483 648), which corresponds to December 13, 1901, 20:45:52 UTC. From the system's point of view, time jumps backward 136 years instantaneously.

Why it happens

Unix timestamps were originally stored as time_t, a signed 32-bit integer on most early Unix systems. A 32-bit signed integer can hold values from −2 147 483 648 to +2 147 483 647 — that is exactly 2³¹ − 1 seconds after the epoch, or about 68 years. Adding 68 years to January 1, 1970 lands on January 19, 2038.

On 64-bit systems, time_t is a 64-bit integer, which extends the range to roughly 292 billion years — well beyond any practical concern. The problem is the large installed base of embedded systems, legacy software, and databases that were compiled assuming 32-bit time.

What is affected

32-bit Linux kernels — the mainstream Linux kernel switched to 64-bit time_t for 32-bit architectures in 2019 (kernel 5.1). But distributions must also update their C libraries and user-space tools.
Embedded systems — industrial controllers, medical devices, automotive ECUs, routers and IoT devices running 32-bit firmware with no planned update path are the highest-risk category.
Legacy databases — applications storing timestamps as MySQL's TIMESTAMP type (which maxes out on January 19, 2038) or in 32-bit integer columns will encounter errors for any date beyond that.
COBOL and mainframe systems — systems originally using 32-bit time calculations that have not been modernised.
File systems — some older file system implementations store modification times in 32-bit fields.

What is not affected

64-bit Linux, macOS, Windows — all use 64-bit time_t. No overflow risk for any practical date.
JavaScript — Date uses a 64-bit float with millisecond precision, safe until year 275 760.
Python, Java, Go, Rust, C# — all use 64-bit integer timestamps internally.
PostgreSQL TIMESTAMPTZ — stores as 8-byte integer with microsecond precision, safe to year 294 276.
Modern Android and iOS — both compile against 64-bit APIs on 64-bit hardware.

The practical risk profile

For web developers, the 2038 problem is nearly irrelevant — all mainstream languages and databases already use 64-bit timestamps. The real risk lies in three areas:

Legacy business logic — code that sets expiry dates or schedules events more than 12 years in the future may already be generating timestamps beyond 2038. A contract signed today with a 15-year term expires in 2041 — past the overflow boundary.
Embedded systems with long deployment cycles — medical devices or industrial controllers installed in 2010 with 30-year lifespans may still be running in 2038 with unpatched firmware.
MySQL TIMESTAMP columns — MySQL's TIMESTAMP type is limited to values up to 2038-01-19 03:14:07. Applications storing future dates should use DATETIME instead, which has a range to year 9999.

Check your MySQL schemas now: any TIMESTAMP column storing dates that might extend past 2038 should be migrated to DATETIME or BIGINT.