Unix Y2038 — 19 January 2038, 03:14:07 UTC

The last second a signed 32-bit Unix timestamp can name. One second later the value wraps to 13 December 1901. This page is the deadline record. The mechanism is on What is the Year 2038 problem?.

Last good second	`2038-01-19 03:14:07 UTC`
Stored value	`2,147,483,647` (`INT32_MAX`)
Next second, if still 32-bit signed	`−2,147,483,648`
How that value is read	`1901-12-13 20:45:52 UTC`
Epoch	`1970-01-01 00:00:00 UTC`
Unsigned 32-bit ceiling	`2106-02-07 06:28:15 UTC`
10-year risk entry	2028-01-19
15-year risk entry	2023-01-19 — already passed

What actually fails

A 64-bit phone or server with a 64-bit time_t does not hit this second. The residual is narrower: a 32-bit ABI that never opted into time64, a 4-byte field on disk or on the wire, a language binding that still uses int, and firmware that will still be installed in 2037.

It also fails early. Any code that adds a duration to “now” and stores the result in 32 bits overflows as soon as the sum passes 2,147,483,647. The documented case is AOLserver on 12 May 2006: a one-billion-second timeout landed past 2038, the expiry became a date in the past, and the process died. Certificate generators, lease maths and 15-year maintenance plans do the same thing.

How to see it on a box

getconf LONG_BIT
# 32 means the C long on this userland is 32-bit. time_t may still differ.
cat /usr/include/bits/timesize.h 2>/dev/null
# __TIMESIZE 64 is the glibc time64 build. 32 is not.

Then check storage, not just the clock: inode size and XFS bigtime, MySQL TIMESTAMP, and any INT column whose name is a time. A 64-bit kernel does not widen those.

Neighbouring deadlines

These are different representations that land in the same two years. Do not file them as the same bug.

NTP era 0 — 7 February 2036, unsigned 32-bit seconds since 1900.
DVB-SI — 23 April 2038, 16-bit Modified Julian Date.
GPS week — 20 November 2038, 10-bit week number. Not Unix time.

Risk entry for a given install is deadline minus service life. That is the calculator.