Year 2038 problem: what happens to 32-bit Unix timestamps

Short answer

The year 2038 problem affects systems that store seconds since the Unix epoch in a signed 32-bit integer. Its maximum is 2147483647, corresponding to 2038-01-19 03:14:07 UTC. One second later no longer fits that representation, although Unix time and systems using wider ranges continue beyond it.

The exact boundary

A signed 32-bit integer uses one sign bit and has 31 bits for a positive value:

maximum = 2³¹ - 1 = 2147483647 seconds

The boundary converts as follows:

2147483647 → 2038-01-19T03:14:07Z
2147483648 → 2038-01-19T03:14:08Z

The second number is a valid timestamp value but cannot fit in a signed 32-bit integer. Check both values with the Unix timestamp converter using seconds and UTC.

What overflow means

The result depends on the language, storage type, and operation. A system using wrapping arithmetic could reinterpret the highest bit and produce a negative value. Another might throw an error, reject the date, or clamp the field. There is no single incorrect date guaranteed for every program.

The limitation belongs to the type used to store or transport the instant, not to the definition of Unix time. Changing how a date is displayed does not widen that type.

Systems worth checking

• Database columns storing Unix seconds in a 32-bit integer.
• Binary formats and protocols with a signed four-byte time field.
• Old firmware, embedded devices, and systems retaining a legacy ABI.
• Code narrowing a timestamp before validating its range.
• Expiry, certificate, or scheduling calculations already reaching past 2038.

A modern operating system can still carry the problem in a file format, database, library, or downstream integration using the old representation.

Seconds, milliseconds, and JavaScript

Multiplying by 1,000 does not solve the problem if the destination is still a 32-bit integer; it reaches its limit much earlier. JavaScript Date uses a numeric millisecond value with a different range. A date working in a browser does not prove it fits in the receiving system.

Keep the unit with the value and test the limits of the actual contract, not only those of the conversion interface.

How to test an integration

Include at least 0 for the epoch, 2147483647 for the last signed 32-bit second, 2147483648 for the first value above it, a practical later date such as 2040, and a negative value if dates before 1970 are supported.

Inspect the stored value, the API response, and the recovered UTC date. A test that only checks whether the request succeeds can miss a truncated date.

Mitigation

Use a representation with enough range from end to end and migrate stored data before later dates become operational requirements. Document unit, signedness, and width; validate before conversion; and review every boundary where the value changes type.

The POSIX rationale for seconds since the epoch documents the 2038 overflow of implementations using signed 32-bit time_t. The risk is specific to that representation, not a universal expiration of Unix timestamps.