Unix Timestamps: What the Number Means and How to Read It

A Unix timestamp is one number: the count of seconds since 00:00:00 UTC on 1 January 1970. 1789776000 is 19 September 2026 at midnight UTC. That is the entire definition. There is no time zone in it, no calendar, no formatting — just a running count from a fixed instant that every machine agrees on.

That fixed instant is called the Unix epoch. Values before it are negative, values after it tick up by one every second, and because the whole thing is arithmetic rather than a date, two timestamps can be compared, sorted and subtracted without anyone having to know how many days are in February.

Why count seconds instead of storing a date?

Because integers behave and dates do not. Months run 28 to 31 days. Leap years happen every four years, except every hundred, except every four hundred. Clocks jump forward and back twice a year in some countries and never in others, and countries change their minds about which group they are in. Text dates are worse still: 03/04/2026 is two different days depending on who wrote it.

A timestamp dodges all of that. "Which came first" is a comparison. "How long between them" is a subtraction. Sorting a log is sorting numbers. The value fits in 8 bytes, survives being written to a file or a URL without escaping, and anything that can read an integer can read it.

The price is that a person cannot read it, and that a timestamp can only ever mean an instant. It cannot express "9am, whatever that turns out to mean in Madrid next March", which is a real thing calendars need to store and a real reason a timestamp is sometimes the wrong tool.

How to read one in your head

You will not get the minute, but you can get the year and the rough month in two divisions.

1. Divide by 86,400 — the number of seconds in a day. That gives you days since 1 January 1970. The remainder is seconds past midnight UTC.
2. Divide the days by 365.25 for years since 1970. Add that to 1970 for the year; the fraction left over, times 12, is roughly the month.

Take 1789776000. Divided by 86,400 it is exactly 20,715 days, with nothing left over, so it lands precisely on midnight UTC. 20,715 ÷ 365.25 is 56.7, so 1970 + 56 gives 2026, and 0.7 × 12 puts it around the ninth month. The real answer is midnight UTC on 19 September 2026, which is close enough for sanity-checking a log line.

A few anchor points are worth memorising, because they let you place any number instantly:

When the exact minute matters, do it properly. Paste the number into the timestamp converter and it tells you which unit it guessed from the digit count, then gives you local time, UTC, both ISO 8601 forms and how far from now that instant is. It runs in the page, so the value never goes anywhere.

Seconds, milliseconds, or something else?

This is where most timestamp bugs actually come from. Unix tools, most SQL databases and a great many APIs count whole seconds. JavaScript, Java and anything descended from them count milliseconds. Go and some tracing systems count nanoseconds. All of them are called "the timestamp" in the documentation.

Count the digits. For any date near the present, the length gives it away:

Those lengths are stable for a lifetime. A seconds timestamp has been 10 digits since 9 September 2001 and stays that way until 2286.

The two ways of getting it wrong are not equally visible. Hand milliseconds to something expecting seconds and you land nearly 57,000 years in the future, which somebody notices within the hour. Hand seconds to something expecting milliseconds and you land in January 1970: new Date(1789776000) in JavaScript is 21 January 1970, not September 2026. That is a plausible-looking wrong answer that sorts quietly to the top of every list and never throws. If a date in your app reads 1970, you are out by a factor of 1000.

Does a Unix timestamp have a time zone?

No, though plenty of code is written as if it did. The number is defined against UTC, but it does not carry a zone the way a formatted date does. It names an instant. The zone is applied when you display it, which is why the same timestamp shows 09:00 in London and 17:00 in Tokyo and both screens are correct.

The damage is done in the other direction. Somebody reads the digits off a local wall clock, converts them without supplying the offset, and stores the result. The stored instant is now wrong by the offset, and the size of the error changes twice a year when daylight saving moves. If the value came from a human's calendar rather than from a machine's clock, store the zone name — Europe/Madrid, not +01:00 — next to it. An offset is a fact about one date; a zone is a rule.

Where you will run into one

• Tokens. A JWT's exp, iat and nbf fields are Unix seconds, which is why the claims inside a JWT look like a wall of ten-digit numbers.
• The shell. date +%s prints the current timestamp in seconds on Linux and macOS.
• Databases. MySQL's FROM_UNIXTIME() and PostgreSQL's to_timestamp() both take seconds.
• Spreadsheets. Excel and Google Sheets count days from a different zero, so the conversion is =A1/86400+25569, formatted as a date. The result is UTC.
• Identifiers. UUID version 7 carries a 48-bit millisecond timestamp in its first six bytes, which is the whole point of it: the IDs sort by creation time.

What breaks: 2038, negative dates and leap seconds

2038. A signed 32-bit counter maxes out at 2,147,483,647 seconds, which is 03:14:07 UTC on 19 January 2038. One second later it wraps to a negative number and the date reads December 1901. Your laptop is fine — 64-bit time covers roughly 292 billion years in each direction — but 32-bit values are still sitting in embedded firmware, in old file formats and in database columns. MySQL's TIMESTAMP type is capped at exactly that 2038 instant while DATETIME is not, so a mortgage end date or a certificate expiry stored in the wrong column is already broken today.

Negative values. A birth date in 1965 is a perfectly valid negative timestamp, and plenty of software refuses it anyway: unsigned columns, some date libraries and many APIs reject anything below zero. Test pre-1970 dates rather than assuming.

Leap seconds. POSIX defines every day as exactly 86,400 seconds, so the 27 leap seconds inserted into civil time between 1972 and the last one on 31 December 2016 simply do not appear in the count. The benefit is that converting a timestamp to a date is arithmetic with no lookup table. The cost is that a Unix timestamp cannot name a leap second at all, and different systems disagree about what happens during one.

Precision. A seconds timestamp cannot tell two events in the same second apart. If you are ordering events, that matters, and it is the usual reason for reaching for milliseconds.

When a timestamp is the wrong answer

Use one for anything that happened: log lines, created-at fields, token expiry, cache timestamps. Do not use one for a date with no time attached — a birthday, an invoice date, a public holiday. Storing "14 July" as a timestamp forces you to pick a midnight in some zone, and it will be the wrong day for somebody. A plain YYYY-MM-DD string is the correct type there.

The same goes for durations. Subtracting two timestamps gives you seconds, and turning seconds into "two months and four days" needs calendar rules a timestamp deliberately threw away. For that kind of question a date difference calculator is the shorter route, and counting the days between two dates covers why the answer depends on which end you include.

Last updated September 19, 2026