What is the Unix timestamp for January 19, 2038?

The Unix timestamp for January 19, 2038 at 03:14:07 UTC is 2,147,483,647 — the maximum value of a 32-bit signed integer (2^31 - 1). This is the exact moment the Year 2038 overflow occurs on 32-bit systems.

Is Y2K38 the same as Y2K?

No. Y2K (Year 2000 problem) was caused by programs storing years as 2-digit numbers. Y2K38 is caused by storing Unix timestamps as 32-bit signed integers that overflow in 2038. Different root causes, different affected systems.

Will the internet break in 2038?

Probably not significantly. Most internet infrastructure has already migrated to 64-bit systems. The risk is concentrated in embedded systems, legacy IoT devices, and software that has not been updated in decades. Modern operating systems, programming languages, and databases are already safe.

Guide

The Year 2038 Problem (Y2K38) Explained

Q: What is the Year 2038 problem?

The Year 2038 problem (Y2K38) is a bug where systems using 32-bit signed integers to store Unix timestamps will overflow on January 19, 2038 at 03:14:07 UTC. The maximum value of a 32-bit signed integer is 2,147,483,647. One second later, the integer wraps to -2,147,483,648, which corresponds to December 13, 1901.

On January 19, 2038 at 03:14:07 UTC, the Unix timestamp 2,147,483,647 — the maximum value of a 32-bit signed integer — will overflow. Here is what that means, which systems are affected, and why most modern code is already safe.

What is the Year 2038 problem?

Unix timestamps are traditionally stored as a signed 32-bit integer counting seconds since January 1, 1970 00:00:00 UTC. The maximum value of a 32-bit signed integer is 2,147,483,647 — which corresponds to January 19, 2038 at 03:14:07 UTC. One second after that moment, the integer overflows to -2,147,483,648. Interpreted as a Unix timestamp, that negative value corresponds to December 13, 1901 — sending affected systems nearly 137 years into the past.

The overflow values

2^31 − 1 = 2,147,483,647 (maximum 32-bit signed integer)
2,147,483,647 as a date = January 19, 2038 03:14:07 UTC
2,147,483,647 + 1 overflows to −2,147,483,648 (the most negative 32-bit value)
−2,147,483,648 as a date = December 13, 1901 20:45:52 UTC

Which systems are at risk?

The problem affects systems that store timestamps as 32-bit signed integers:

Embedded systems and microcontrollers with 32-bit time_t
Legacy C and C++ code compiled for 32-bit targets using time_t or int for timestamps
Old Linux kernels (before 5.6) on 32-bit hardware still in production
MySQL TIMESTAMP columns — limited to 2038-01-19; use DATETIME instead
Some network protocols and file formats that encode timestamps as 32-bit values
Firmware in industrial control systems and IoT devices with decade-long lifespans

Which systems are safe?

Most modern code and infrastructure is already unaffected:

Any 64-bit OS — Linux (glibc 2.34+ also fixes 32-bit hardware), macOS, Windows
Python — timestamps use 64-bit floats, safe well past the year 292 million
JavaScript — Date uses 64-bit IEEE 754 floats, safe to year 275,760
Go and Rust — use int64 for time internally, safe for billions of years
Java — java.time.Instant uses long (64-bit), safe to year ~292 million
PostgreSQL TIMESTAMP — stores dates beyond 2038 correctly
MySQL DATETIME — range 1000-01-01 to 9999-12-31, unaffected

Frequently asked questions

What is the Year 2038 problem?: Systems storing Unix timestamps as 32-bit signed integers will overflow on January 19, 2038 at 03:14:07 UTC. The integer wraps from 2,147,483,647 (max) to -2,147,483,648 (min), which systems interpret as December 13, 1901.
Is Y2K38 the same as Y2K?: No. Y2K was caused by storing years as 2-digit numbers. Y2K38 is caused by storing Unix timestamps as 32-bit signed integers that overflow in 2038. Different root causes, different systems affected.
Will modern systems be affected?: No. Any system using 64-bit time_t — which includes all modern 64-bit operating systems and programming languages — is safe. The risk is in embedded systems, old firmware, and legacy C code compiled for 32-bit targets.
What is the max Unix timestamp for 32-bit systems?: 2,147,483,647 — the maximum value of a signed 32-bit integer (2^31 - 1). This corresponds to January 19, 2038 at 03:14:07 UTC.