Unix Timestamp -2147483648: The 1901 Limit and Negative Timestamps

Unix timestamp -2147483648 is Friday, 13 December 1901, 20:45:52 UTC. It is the smallest number a signed 32-bit integer can store, so it is the earliest instant a 32-bit Unix clock can represent.

You will rarely see it because someone meant 1901. Much more often, it appears after a Year 2038 overflow, or when code struggles with negative timestamps in general.

Unix timestamp -2147483648 at a glance

Try it in the Unix Timestamp Converter.

1901 in different time zones

Look at Kolkata. In 1901 India did not yet use today's UTC+05:30. The IANA time zone database, which browsers and operating systems use, records a historical offset of +05:21:10 for that period, so the local time ends in :07:02 rather than a round number.

Historical time zones are full of details like this. Data before 1970 in the time-zone database is best-effort, and different systems may show slightly different local times for old dates. The UTC value is the only reliable reference.

Why the minimum is -2147483648

A signed 32-bit integer in two's-complement form ranges from −2³¹ to 2³¹ − 1:

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

The range is not symmetrical: there is one more negative value than positive values. Counted from the Unix epoch, 2³¹ seconds is about 68 years, which reaches back from 1970 to the end of 1901.

A 1901 date usually means overflow

When a signed 32-bit counter passes 2147483647, it wraps around to -2147483648. So the first second after the 2038 limit becomes the earliest second of the 32-bit range:

const next = (2147483647 + 1) | 0 // -2147483648
new Date(next * 1000).toISOString() // "1901-12-13T20:45:52.000Z"

Any value slightly past the limit lands shortly after 13 December 1901. A value far past it lands later in the 20th century. A date calculation that adds 20 years to a date in 2030 may therefore produce something in the 1910s:

const in2030 = 1893456000 // 2030-01-01 00:00:00 UTC
const twentyYears = 20 * 365 * 86400

const overflowed = (in2030 + twentyYears) | 0
new Date(overflowed * 1000).toISOString() // "1913-11-20T17:31:44.000Z"

If you see dates between 1901 and about 1970 in data that should be recent or in the future, look for a 32-bit signed conversion somewhere in the pipeline.

Working with negative timestamps

Negative Unix timestamps are completely valid: they represent instants before 1970. -1 is 1969-12-31T23:59:59Z, and -86400 is exactly one day before the epoch. Birth dates, historical archives and genealogy data depend on them.

Support varies, though:

• JavaScript handles negative values correctly: new Date(-2147483648 * 1000) works as expected.
• Python datetime.fromtimestamp() can raise OSError for negative values on some platforms, notably Windows. A portable alternative is adding a timedelta to the epoch.
• MySQL FROM_UNIXTIME() does not accept negative arguments, and the TIMESTAMP column type starts in 1970. Use DATETIME for older dates.
• PostgreSQL to_timestamp() accepts negative values.
• Validation code that assumes "timestamps are positive" or "timestamps have 10 digits" rejects every date before 1970.

Integer division and negative time

Negative timestamps expose a subtle arithmetic bug. To get the day number of a timestamp you divide by 86,400, but many languages truncate toward zero instead of rounding down:

Math.trunc(-1 / 86400) // -0  wrong: points to 1970-01-01
Math.floor(-1 / 86400) // -1  correct: 1969-12-31

C, C++, Java, C#, Go and JavaScript's Math.trunc or | 0 all truncate. Python's // operator floors, so -1 // 86400 is correctly -1. When you compute dates by hand, use floor division, or leave the work to the language's date library.

Converting -2147483648 in code

JavaScript

new Date(-2147483648 * 1000).toISOString() // "1901-12-13T20:45:52.000Z"

Python

from datetime import datetime, timedelta, timezone

epoch = datetime(1970, 1, 1, tzinfo=timezone.utc)
(epoch + timedelta(seconds=-2_147_483_648)).isoformat()
# '1901-12-13T20:45:52+00:00'

Shell

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

PostgreSQL

SELECT to_timestamp(-2147483648) AT TIME ZONE 'UTC';
-- 1901-12-13 20:45:52

Dates before 1901

A signed 32-bit timestamp cannot represent anything earlier than December 1901. For older dates, use a wider type:

• Signed 64-bit seconds, which cover about 292 billion years in each direction.
• JavaScript Date, which works from the year −271821 to +275760.
• Native date-time types in your database, such as PostgreSQL timestamptz or MySQL DATETIME.

For calendar-only values such as historical birthdays, consider storing a plain date instead of a timestamp at all. The main guide explains when a date should not be a timestamp.

Summary

Unix timestamp -2147483648 is 1901-12-13 20:45:52 UTC, the minimum of a signed 32-bit integer. A 1901 date in real data usually means a timestamp after 2038 overflowed. Negative timestamps are valid, but test them explicitly: some functions reject them, and truncating division shifts them by a day.

Check the value in the Unix Timestamp Converter, see the opposite end of the range in 2147483647 and the Year 2038 problem, and compare unsigned time in 4294967295 and the Year 2106 problem.