Unix Timestamps Explained: Epoch, Seconds vs Milliseconds

A Unix timestamp like 1700000000 shows up in logs, databases, JWTs and APIs everywhere. It looks cryptic but the idea is simple — and understanding it saves you from a class of annoying bugs.

What is a Unix timestamp?

A Unix timestamp (also called epoch time) is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, a moment known as the Unix epoch. It's a single integer that represents an exact instant in time, which makes it ideal for computers: easy to store, compare and do arithmetic with.

Why 1970? It's simply the date the early Unix designers chose as a convenient starting point. Everything before it is represented as a negative number.

The seconds-vs-milliseconds trap

This is the bug that catches everyone. Classic Unix time counts seconds, but JavaScript and many APIs use milliseconds (seconds × 1000). Mixing them up sends your date wildly off:

• A 10-digit number is almost always seconds (e.g. 1700000000 = Nov 2023).
• A 13-digit number is almost always milliseconds (e.g. 1700000000000).

If you feed seconds where milliseconds are expected, your date lands in 1970; the reverse throws it thousands of years into the future. When a timestamp looks wrong, check the unit first.

Timestamps have no timezone

A common source of confusion: a Unix timestamp is not in any timezone. It's a single instant — the same number all over the world. The timezone only matters when you display it. That's why a good converter shows you both UTC and your local time: they're two human representations of the identical underlying value. When you store time, store the timestamp (or UTC); apply timezones only at display time.

Where you'll use it

• Reading created_at columns or log lines.
• Checking a JWT's exp (expiry) and iat (issued-at) claims.
• Computing cache TTLs and "X minutes ago" displays.
• Comparing two events to see which came first.

The 2038 problem

Systems that store Unix time in a signed 32-bit integer can only count up to 2,147,483,647 seconds, which is reached on 19 January 2038. After that, the counter overflows and wraps to a negative number — a distant cousin of the Y2K bug. Modern systems use 64-bit time and are unaffected for billions of years, but legacy embedded systems and old code can still be at risk. It's worth knowing if you maintain anything old.

Try it

Convert epoch time to a readable date and back — with automatic seconds/milliseconds detection and both UTC and local output — using our Unix timestamp converter. If you're working with a JWT's expiry claim, pair it with the JWT decoder, and for recurring schedules see the cron explainer.