Unix Timestamp 2147483647 and the Year 2038 Problem Explained

Unix timestamp 2147483647 is Tuesday, 19 January 2038, 03:14:07 UTC. It is the largest number a signed 32-bit integer can store, so it is the last second that a 32-bit Unix clock can represent.

One second later, systems that still use 32-bit signed time overflow. This is the Year 2038 problem, sometimes called Y2038 or the "Epochalypse". Modern 64-bit systems are not affected in practice, but 32-bit time still lurks in embedded devices, file formats, databases and ordinary application code.

Unix timestamp 2147483647 at a glance

Open it in the Unix Timestamp Converter.

The 2038 limit in different time zones

In the Americas, the overflow happens on the evening of 18 January 2038, local time. Local times are based on current time-zone rules and could change before 2038; the UTC instant will not.

Why the limit is 2147483647

A signed 32-bit integer uses one bit for the sign and 31 bits for the value. The largest positive number it can represent is:

2^31 − 1 = 2147483647 = 0x7FFFFFFF

The traditional C type for Unix time, time_t, was a signed 32-bit integer on many older systems. Counting seconds from the Unix epoch, 2³¹ − 1 seconds is about 68 years, which takes you from 1970 to January 2038.

What happens one second later

Adding one to 0x7FFFFFFF flips the sign bit. In two's-complement arithmetic, the result is the most negative 32-bit value:

0x7FFFFFFF  =  2147483647  →  2038-01-19 03:14:07 UTC
0x80000000  = -2147483648  →  1901-12-13 20:45:52 UTC

So a clock that keeps counting in 32 bits jumps from January 2038 back to December 1901. (In C, signed overflow is technically undefined behaviour; on typical hardware the value wraps as shown.) You can see the same thing in JavaScript, whose bitwise operators work on signed 32-bit integers:

const wrapped = (2147483647 + 1) | 0 // -2147483648
const stored = new Int32Array([2147483648])[0] // -2147483648

Real software reacts in different ways:

• Wrap-around. Dates show 1901. Sorting, expiry checks and "time since" calculations break silently.
• Errors. Functions reject the value, return NULL, or throw an overflow exception.
• Clamping. Some code caps the value at 2147483647, so every later date becomes 03:14:07 on 19 January 2038.

The mirror-image value, and what a 1901 date in your logs usually means, is covered in Unix timestamp -2147483648.

What is affected

The operating system is only one layer. The Year 2038 problem appears wherever time is stored or passed in 32 bits.

Operating systems and C libraries

• 64-bit systems use a 64-bit time_t and are not affected in practice.
• 32-bit Linux gained 64-bit time support in the kernel (completed around version 5.6) and in C libraries. glibc supports _TIME_BITS=64 on 32-bit targets from version 2.34, and musl switched 32-bit targets to 64-bit time_t in version 1.2. Programs still need to be rebuilt with those settings to benefit.
• Embedded and IoT devices such as routers, industrial controllers, cars and medical devices often run 32-bit software for decades and are the hardest to update.

File systems and file formats

• Older file systems stored timestamps in 32-bit fields. For example, ext4 with small 128-byte inodes is limited to 2038, while ext4 with 256-byte inodes and XFS with the bigtime feature extend far beyond it.
• Binary formats and network protocols with a 4-byte signed timestamp field cannot represent 2038 without a format change.

Databases

• MySQL's TIMESTAMP column type has a documented maximum of 2038-01-19 03:14:07 UTC. DATETIME does not have this limit.
• Integer columns declared as 32-bit INT overflow when you store Unix seconds past 2038. Use BIGINT.
• PostgreSQL timestamp and timestamptz types have a range far beyond 2038.

Application code

Even on 64-bit systems, application code can reintroduce the bug:

• Casting a timestamp to int or int32 in C, C++, C#, Go or Rust.
• Java or Kotlin fields declared as int for "seconds since epoch" instead of long.
• JavaScript bitwise tricks such as ts | 0 or ~~ts for truncation.
• Protocol Buffers, Thrift or custom schemas that use int32 or sint32 for timestamps.
• 32-bit builds of runtimes, for example PHP on 32-bit platforms, where integers are 32-bit.

The problem starts before 2038

Any code that calculates a future date needs to represent that date now. A 20-year schedule calculated in 2018, a 15-year retention rule applied in 2023, or a 10-year certificate issued in 2028 all need values beyond 2147483647 today.

That is why 2038 bugs are already appearing in production. The 2000000000 milestone, in May 2033, is less than five years before the limit, and it is a good reminder of how little room remains.

How to test for the Year 2038 problem

1. Round-trip boundary values through every layer: API, serializers, database, cache, queues and client code.

   2147483647   2038-01-19 03:14:07 UTC  last int32 second
   2147483648   2038-01-19 03:14:08 UTC  first value that overflows int32
   4102444800   2100-01-01 00:00:00 UTC  far-future sanity check
   

2. Calculate far-future dates. Add 15 or 20 years to "now" and check that the result is after 2038, not in 1901.

3. Run with a fake clock. On Linux, tools such as libfaketime can start a process with a clock set just before the limit:

   faketime '2038-01-19 03:14:00' ./your-app
   

4. Search the code for 32-bit types near time values: int32, Int32Array, | 0, INT columns, TIMESTAMP columns, and 4-byte fields in binary formats.

5. Test on real target hardware when you ship to 32-bit or embedded platforms.

Converting 2147483647 in code

JavaScript

new Date(2147483647 * 1000).toISOString() // "2038-01-19T03:14:07.000Z"
new Date(2147483648 * 1000).toISOString() // "2038-01-19T03:14:08.000Z" (no overflow)

Python

from datetime import datetime, timezone

datetime.fromtimestamp(2_147_483_647, tz=timezone.utc).isoformat()
# '2038-01-19T03:14:07+00:00'

Shell

date -u -d @2147483647     # GNU/Linux
date -u -r 2147483647      # macOS / BSD

C (64-bit time_t)

#include <stdio.h>
#include <time.h>

int main(void) {
    time_t t = 2147483648;  /* one second past the 32-bit limit */
    char buf[32];
    strftime(buf, sizeof buf, "%Y-%m-%d %H:%M:%S", gmtime(&t));
    printf("%s UTC, sizeof(time_t) = %zu\n", buf, sizeof(time_t));
}

On a system with 64-bit time_t, this prints 2038-01-19 03:14:08 UTC and a size of 8.

Summary

Unix timestamp 2147483647 is 2038-01-19 03:14:07 UTC, the last second a signed 32-bit integer can hold. After it, 32-bit time wraps to 1901, fails, or clamps. Modern 64-bit platforms are safe, but 32-bit values survive in embedded systems, file formats, database columns and application code, and future-date calculations hit the limit years early.

Check boundary values in the Unix Timestamp Converter. For what lies beyond 2038 if you switch to unsigned 32-bit, read Unix timestamp 4294967295 and the Year 2106 problem, and for the fundamentals, see Unix Timestamps Explained.