Developer Tool
At 03:14:07 UTC on January 19, 2038, a signed 32-bit Unix timestamp runs out of room and wraps around to a negative number — 1901. Here's exactly how long is left.
Signed 32-bit integers max out at 2,147,483,647. Once the Unix timestamp — seconds since January 1, 1970 — reaches that number, incrementing it by one flips the sign bit, and the value jumps to -2,147,483,648, which decodes as December 13, 1901. Any system still storing timestamps as a signed 32-bit integer (older embedded devices, some 32-bit Unix systems, certain database column types, and old file formats) is at risk. For the full explanation, see The Year 2038 Problem.
Most 64-bit systems and modern language runtimes already use 64-bit or larger integers for timestamps, which pushes the equivalent overflow date roughly 292 billion years out — effectively never. The real risk is legacy 32-bit code, embedded firmware, and any file format or protocol that was never updated. If you write systems software, it's worth an audit; if you don't, this is mostly a fun deadline to watch.
Related
The full explanation of what breaks, and why.
How this overflow compares to the original Y2K bug.
See timestamps in seconds, ms, µs, and ns side by side.