2147483647 and the year 2038 problem
2147483647 is 03:14:07 UTC on Tuesday 19 January 2038: the largest number a signed 32-bit integer can hold. One second later, a 32-bit time_t overflows to -2147483648, which reads as 20:45:52 UTC on Friday 13 December 1901.
2147483647 read as seconds since 1970-01-01 00:00 UTC is Tuesday, 2038-01-19 03:14:07 UTC.
- ISO 8601 (UTC)
2038-01-19T03:14:07Z- Your time zone
shown when JavaScript runs- RFC 2822 / email
Tue, 19 Jan 2038 03:14:07 +0000- HTTP date
Tue, 19 Jan 2038 03:14:07 GMT- Seconds
2147483647- Milliseconds
2147483647000- Day of week (UTC)
Tuesday- ISO week
2038-W03- Day of year
19- Fits in 32-bit signed time_t
yes
What to know
Unix time counts seconds since 1970-01-01 00:00:00 UTC. For decades it was stored in a signed 32-bit time_t, which tops out at 2^31 - 1. Software that still stores or transmits time in 32 bits will wrap to 1901, or treat the time as negative, at that moment.
64-bit Linux, macOS and Windows use a 64-bit time_t and are not affected in the kernel. Linux added 64-bit time for 32-bit architectures in kernel 5.6 (2020), and glibc 2.34 lets 32-bit programs opt in with _TIME_BITS=64. What remains at risk: embedded devices, old 32-bit binaries, file formats and database columns with 32-bit timestamps (MySQL's TIMESTAMP type, for example, ends at 2038-01-19 03:14:07 UTC), and any protocol field that is 32 bits wide.
Dates after 2038 already appear in software today: 30-year mortgages, certificates and scheduled jobs. Testing with a clock set past 2038 finds these bugs before the date does.
Gotchas
- Unsigned 32-bit time lasts until 2106, but cannot express dates before 1970.
- JavaScript dates are milliseconds in a 64-bit float: safe until the year 275760.
- Leap seconds are not counted in Unix time: every day is exactly 86,400 seconds.