What Is a Unix Timestamp?

A Unix timestamp is the number of seconds that have passed since 1970-01-01T00:00:00 UTC — a moment called the Unix epoch. That is the entire definition. A value like 1785067200 is not a date in any human sense; it is a distance, measured in seconds, from one agreed-upon starting line. Dates before 1970 are simply negative distances: -86400 is 31 December 1969. This post covers what that number does and does not encode, and how to move between it and a readable date without introducing bugs. For the wider picture — time zones, storage formats, cron scheduling — start with The Complete Guide to Timestamps, Time Zones and Cron.

Why 1970?

The epoch is an engineering decision, not a cosmic one. The first Unix systems in the early 1970s tracked time in sixtieths of a second inside a 32-bit integer, which covered barely two and a half years before overflowing. Moving to a one-second tick stretched the same 32 bits across more than a century, and the start of 1970 was picked as a recent, tidy reference — close enough to the present that no bits were wasted on medieval history, far enough back to cover the records anyone cared about.

The choice stuck far beyond Unix. Java, JavaScript, Python, Go, PostgreSQL, HTTP caches, JWT tokens, and most log formats all count from the same instant. It is one of the few genuinely universal conventions in computing.

The Property That Matters: No Time Zone

The single most useful thing about a timestamp is that it has no time zone at all. It cannot have one. It is a count from a fixed instant, and that instant is the same everywhere in the world.

Take 1785067200. Rendered in different zones it looks like this:

Time zone	Rendered date and time
UTC	2026-08-07 00:00:00
America/New_York	2026-08-06 20:00:00
Europe/Berlin	2026-08-07 02:00:00
Asia/Tokyo	2026-08-07 09:00:00

Four strings, four different calendar readings, two different dates — and one single instant. Nothing changed about the number; only the lens changed. People often say "timestamps are in UTC," which is a useful shorthand but slightly wrong. The correct statement is that the epoch itself is defined in UTC, so converting a timestamp without applying any zone gives you the UTC rendering by default.

This is why timestamps are the safest thing to put in a database column, a cache key, an API payload, or a log line. There is no offset to lose, no abbreviation to misread, no ambiguity when the clocks change. You store the instant and render it per user at the last possible moment.

Seconds, Milliseconds, and the Digit Test

The original convention counts seconds. Several major platforms count milliseconds instead, and a few go finer:

Unit	Digits (current era)	Where you meet it
Seconds	10	date +%s, PHP time(), MySQL UNIX_TIMESTAMP(), JWT exp
Milliseconds	13	JavaScript Date.now(), Java System.currentTimeMillis()
Microseconds	16	Postgres internal storage, some tracing systems
Nanoseconds	19	Go UnixNano(), Python time.time_ns()

Digit counting is a reliable field test for anything in the current century. The classic symptoms of getting it wrong are unmistakable: a date in January 1970 means milliseconds were parsed as seconds, and a date tens of thousands of years in the future means seconds were parsed as milliseconds. Neither fails loudly, which is why they reach production. If you are not certain what you have, drop it into the Unix Timestamp Converter, which detects the unit and shows the result in UTC and your local zone side by side.

Converting in Practice

Going from a timestamp to a date, in the languages you are most likely to be using:

// JavaScript — note: milliseconds
new Date(1785067200 * 1000).toISOString();  // "2026-08-07T00:00:00.000Z"

from datetime import datetime, timezone
datetime.fromtimestamp(1785067200, tz=timezone.utc)  # 2026-08-07 00:00:00+00:00

date -u -d @1785067200        # GNU coreutils
date -u -r 1785067200         # BSD / macOS

SELECT to_timestamp(1785067200);        -- PostgreSQL
SELECT FROM_UNIXTIME(1785067200);       -- MySQL, uses session time zone

Two habits prevent most conversion bugs. First, always pass the time zone explicitly. Python's datetime.fromtimestamp(x) with no tz argument silently uses the machine's local zone, so the same code produces different output on a developer laptop and a UTC server. Second, be explicit about the unit at every boundary — name variables expiresAtMs rather than expiresAt and the class of error disappears.

Going the other way, from a calendar date to a timestamp, has one extra decision: which zone the input date is meant to be in. "2026-08-07 09:00" is a different instant in Berlin than in Tokyo, so the conversion needs a zone to resolve it. The Date to Unix Timestamp Converter makes that choice visible instead of assuming, and the Unix Epoch to Date Formatter handles the reverse with the same explicitness. Both run entirely in your browser.

What Timestamps Do Not Do

A timestamp records an instant, not a calendar intention. If a user schedules a recurring 09:00 meeting in Chicago for next year, storing the computed timestamp is wrong: if the DST rules change between now and then — and legislatures do change them — the meeting fires at the wrong local hour. Future civil events need a local time plus an IANA zone name, so the instant can be recomputed later. This distinction is exactly the one that makes scheduled jobs tricky too, which is why cron expressions specify wall-clock fields rather than epoch values, and why picking the right cron schedule means thinking about the zone the scheduler runs in.

Timestamps also have limits set by their integer width. The 32-bit signed form runs out at 2,147,483,647 seconds, which is 2038-01-19T03:14:07 UTC. Sixty-four-bit values, which every modern platform uses, push that limit past the expected lifetime of the sun.

Conclusion

A Unix timestamp is one number measuring one distance from one fixed instant, and its lack of a time zone is a feature rather than an omission. Store instants as timestamps or as UTC ISO 8601 strings, keep the unit unambiguous in your variable names and schemas, apply a time zone only when rendering for a human, and reach for a local-time-plus-zone-name pair when the thing you are recording is a future calendar commitment rather than a past event.