What Is a Unix Timestamp? A Plain-English Guide

Somewhere in almost every app you use today, time is being stored not as "14 September 2026, 3:00pm" but as a single large number like 1789045200. That number is a Unix timestamp, and it is one of the most quietly important conventions in computing. It turns the messy, human idea of a date into something a machine can compare with plain arithmetic.

You do not need to be a programmer to benefit from understanding it. Unix timestamps show up in spreadsheets, API responses, log files, and the expiry field of the cookies sitting in your browser right now. This guide explains what the number actually means, the history behind its odd starting point, and the two or three gotchas that catch out even experienced developers.

What a Unix timestamp actually is

A Unix timestamp is the number of seconds that have elapsed since a fixed reference moment called the Unix epoch: midnight UTC on 1 January 1970. So a timestamp of 0 means exactly that instant, 60 means one minute later, and 1789045200 means a specific moment more than fifty years on.

Because it is just a running count of seconds, comparing two moments becomes trivial: the larger number is the later time, and subtracting one from the other gives the exact seconds between them. No month lengths, no leap years, no time zones to reconcile — just integers. You can turn one back into a readable date in a moment with a unix timestamp converter.

Why 1970, of all years?

The choice looks arbitrary, and to some extent it was. The Unix operating system was being built at Bell Labs around 1969 to 1971, and its engineers needed a convenient, round starting point close to the present day. The beginning of 1970 was recent, tidy, and safely in the past.

Early Unix measured time in sixtieths of a second and would have overflowed its counter within a couple of years, so the unit was changed to whole seconds and the epoch settled on 1 January 1970. That decision, made for one operating system, ended up baked into a huge share of the world's software and hardware.

It has no time zone, and that is the point

A Unix timestamp always refers to a moment in UTC. It does not carry a time zone, and it does not need one — it names an absolute instant. The same timestamp is "the same moment" whether you are in Tokyo or Toronto; only the way you *display* it differs.

This is exactly why systems love it. Store the timestamp, and each user's device can render it in their own local time. Store a local time string instead, and you inherit every time-zone and daylight-saving headache going. Our time zones explained guide covers why that display step is the right place to handle zones.

Seconds or milliseconds? The classic bug

Here is the single most common mistake. Classic Unix time counts seconds, but JavaScript — and therefore much of the web — counts milliseconds since the same epoch. So one moment is 1789045200 in seconds but 1789045200000 in milliseconds.

Mix them up and your date is either wrong by a factor of a thousand — flinging you into the year 58,000 or back near 1970 — or off by mere fractions of a second. A quick sanity check: a present-day timestamp in seconds has about 10 digits, while in milliseconds it has about 13.

Dates before 1970: negative timestamps

Nothing stops the count from going negative. A timestamp of -86400 is exactly one day *before* the epoch — 31 December 1969. Historical dates are represented as negative numbers, which most modern date libraries handle without complaint, though some older tools stubbornly refuse anything below zero.

The Year 2038 problem

For decades, many systems stored the timestamp in a signed 32-bit integer. That data type can only count up to 2,147,483,647 — and that many seconds after the epoch falls at 03:14:07 UTC on 19 January 2038. One second later the counter overflows and wraps around to a large negative number, throwing the date back to 1901.

It is the same shape of problem as Y2K, and it is being fixed the same way: by moving to 64-bit integers, which push the overflow billions of years into the future. Most modern systems have already made the switch, but older embedded devices and legacy databases are still being audited.

Leap seconds: the small lie

Strictly speaking, a Unix timestamp is not a perfect count of every second that has physically elapsed since 1970. The official POSIX definition ignores leap seconds — the occasional extra seconds added to keep atomic time aligned with the Earth's slightly irregular rotation.

In practice this means Unix time pretends every day is exactly 86,400 seconds long, even the handful of days that technically had one more. For everyday date maths this is invisible and harmless; for high-precision scientific or financial timing it is a known caveat that specialists handle separately.

Where you will bump into them

• API responses. Most web APIs return dates as Unix timestamps because they are compact and unambiguous.
• Databases and logs. Server logs stamp each event with a timestamp so entries sort and compare cleanly.
• Tokens and sessions. The "exp" (expiry) field in a login token is a Unix timestamp, as are many cookie expiry values.
• Spreadsheets and data science. Sensor and event data often arrives timestamped, ready to be converted for analysis.
• Measuring durations. Subtracting two timestamps gives an exact elapsed time in seconds — see measuring elapsed time.

Storing a timestamp vs a readable date

For data that machines handle, the integer wins; for anything a person reads at a glance, it needs converting first. Weighing the two:

A Unix timestamp is the closest thing computing has to a universal "now" — a single number that means the same instant to every machine on the planet.