Guides

Unix timestamps: what that big number actually means

1753664400 is a moment in time, but not quite the moment most people assume. Here's what the number counts, what it deliberately ignores, and the four ways it goes wrong in real code.

By D. Shin · Published July 28, 2026

A Unix timestamp is a count of seconds since 00:00:00 UTC on 1 January 1970, the "Unix epoch". That's the whole definition. It has no time zone, no calendar, no formatting — just an integer, which is exactly why it turns up everywhere from log files to database columns to JWT expiry fields.

The simplicity is real, and so are the four places it bites.

1. Seconds or milliseconds?

This is the error you will actually hit. Unix and most backend languages count seconds. JavaScript's Date.now(), Java's System.currentTimeMillis() and a lot of JSON APIs count milliseconds. Feed one to something expecting the other and you land in 1970 or somewhere around the year 57,000.

The quick test: a current seconds timestamp is 10 digits. A milliseconds one is 13. If you're looking at a number starting with 17 and it's ten digits long, it's seconds and it's recent.

2. It has no time zone — but your display does

The timestamp itself is unambiguous: one number, one instant, worldwide. Two servers on opposite sides of the planet recording the same event record the same integer. That's the point of it.

Ambiguity arrives at the edges, when you convert. A timestamp rendered as "2026-07-28 09:00" means nothing until you say which zone that's in — and most conversion bugs are a timestamp formatted in local time somewhere, then read as UTC somewhere else. Store the number, convert only at display, and label the zone whenever you show it.

3. Leap seconds don't exist here

Earth's rotation is slightly irregular, so UTC occasionally inserts a leap second, and a minute runs to 61 seconds. Unix time simply doesn't represent them: every day is defined as exactly 86,400 seconds.

So on a leap second, the timestamp either repeats a value or gets stepped over, depending on the system. Most infrastructure now "smears" the extra second across a whole day, nudging the clock imperceptibly slow rather than repeating a number.

The practical consequence: the difference between two Unix timestamps is not exactly the elapsed physical time if a leap second fell between them — it'll be off by a second or so per event. Irrelevant for a session expiry. Not irrelevant for satellite navigation or high-frequency trading, which is why those use their own time scales.

4. Before 1970, the number goes negative

Perfectly legal: −86,400 is 31 December 1969. Plenty of code handles it fine. Plenty doesn't — unsigned integer columns reject it outright, and some libraries silently return garbage. If you're storing birthdates or historical records, test a pre-1970 value before trusting the pipeline.

The 2038 problem

A signed 32-bit integer maxes out at 2,147,483,647. As a Unix timestamp that is 03:14:07 UTC on 19 January 2038. One second later it overflows to negative and the system reads December 1901.

Y2K with better arithmetic, essentially. Modern 64-bit systems use a 64-bit time_t and are fine for longer than the sun will cooperate. What's left is the long tail: 32-bit embedded devices, old file formats with a fixed 32-bit field, database columns declared as 4-byte integers, and protocols that pinned the width in their spec.

And it isn't purely a future problem. Anything computing an expiry more than a decade out — a long-lived certificate, a mortgage term, a retention policy — is doing arithmetic that crosses 2038 today. That's where the first failures have already shown up.

Working with timestamps sanely

• Store UTC, always. Convert to local at the moment of display, never in storage.
• Keep the unit explicit. Name fields expires_at_ms or created_at_s rather than leaving the reader to guess.
• Use 64-bit types for anything new, in code and in the schema.
• Don't do calendar math in seconds. Months and years aren't fixed-length, and neither are DST days.
• Log in ISO 8601 with an offset (2026-07-28T09:00:00Z) when a human will read it. Machine-friendly, unambiguous, sortable as text.

Handy reference points

Rough conversions worth memorising: 86,400 seconds in a day, 604,800 in a week, and about 31.5 million in a year. Enough to sanity-check a suspicious expiry field without opening a converter.