Unix timestamps explained (and the year 2038 problem)

A Unix timestamp is the number of seconds that have elapsed since January 1, 1970, 00:00 UTC — a reference point developers call the epoch. It's a single integer, with no timezone, no locale formatting and no ambiguity, standing in for one exact instant in time. You can convert a Unix timestamp to a readable dateand back with Docuboxer's tool, which runs entirely in your browser and supports both local time and UTC.

Why 1970? There's no deep reason

People sometimes assume January 1, 1970 has some technical significance. It doesn't. It was a practical, largely arbitrary choice made by the engineers designing Unix in the early 1970s — a recent, round date that didn't waste precious memory representing years the system would never need to handle. It stayed fixed for the same reason most low-level conventions stay fixed: once file systems, databases and network protocols started assuming that zero point, moving it would have broken everything built on top of it. Decades later, the Unix epoch is the closest thing computing has to a universal way of representing a moment in time.

Seconds vs. milliseconds: the detail that actually breaks things

This is, in practice, the single most common timestamp bug. Unix defines the epoch in seconds, but plenty of languages and APIs work in milliseconds instead — JavaScript's Date.now() being the most-hit example. The fast way to tell them apart is to count digits: a 10-digit value is seconds (something like 1755561600), a 13-digit value is milliseconds (1755561600000).

Mixing them up produces results that are wrong but rarely loud about it. Parse 13 digits as if they were seconds and you land somewhere around the year 55000. Parse 10 digits as if they were milliseconds and you land in January 1970. Neither throws an error — the math is perfectly valid, the date is just nonsense — which is exactly why these bugs slip into production and only surface when someone spots an invoice dated "1970-01-20" or a subscription that expired before it started. Before converting any timestamp, count the digits first.

The epoch is always UTC — timezone is a display concern

A Unix timestamp carries no timezone information; it's always the count of seconds since the epoch in UTC, full stop. When an interface shows you "August 15, 2026, 9:00 AM" from a raw timestamp, that local time is computed at render time by applying a timezone offset — it isn't stored anywhere in the data itself. The same timestamp produces a different displayed hour for someone in New York, London or Tokyo, but it represents the exact same instant for all three. This distinction saves debugging time: if two systems "disagree on the time," it's almost always a display-layer mismatch (which timezone is being applied), not a problem with the underlying value.

The year 2038 problem

A lot of older systems store the Unix timestamp as a signed 32-bit integer. That data type tops out at 2,147,483,647 — and the epoch reaches that many seconds on January 19, 2038, at 03:14:07 UTC. One second later, the counter overflows: in signed arithmetic, the next value reads as negative, and the computed date jumps backward to December 13, 1901. It's often mentioned in the same breath as the Y2K bug, but the mechanism is different — Y2K was a formatting shortcut (storing two digits instead of four); Y2038 is a hard ceiling built into the data type itself.

Where this is still a genuine risk today: embedded systems and firmware that rarely get patched — industrial controllers, automotive electronics, IoT devices with a decade-plus service life still ahead of them — legacy file formats with 32-bit date fields baked into their spec, and database columns that were typed as a 32-bit INTyears ago in systems nobody has revisited since. Where it's already a non-issue: any modern 64-bit system — which covers the overwhelming majority of current server and desktop software — uses a 64-bit integer for time, with a range that stretches out to roughly the year 292 billion. For those systems, January 19, 2038 is just another Monday.

One honest caveat: leap seconds

The Unix epoch ignores leap seconds— the occasional one-second adjustments added to official clocks to compensate for the fact that Earth's rotation isn't perfectly constant. That's a deliberate simplification: it keeps subtracting two Unix timestamps clean and predictable, always yielding the same number of clock seconds. The tradeoff is that the Unix epoch isn't a physically perfect time scale — two timestamps exactly 86,400 apart don't always correspond to exactly one solar day. For nearly everything developers actually do with timestamps — ordering events, computing expirations, measuring durations — that gap is irrelevant. It only matters if you're building something that needs to track true astronomical time.

Timestamps inside a JWT: also in seconds

If you work with authentication, you'll run into Unix timestamps inside a JWT constantly: the exp (expiration) and iat (issued-at) claims follow the standard Unix convention of seconds since the epoch — not the milliseconds your JavaScript code is probably working with internally. This is a recurring source of bugs when validating tokens manually: compare a seconds-based exp against a milliseconds-based Date.now() without converting first, and a token will look expired a thousand-fold too early, or never expire at all.

Try it with a real timestamp

Open the Unix timestamp converter and paste in 1755561600: you'll see the corresponding date in both your local timezone and UTC, and you can run the conversion the other way from any readable date. If you need to inspect the raw value in another base — say, to debug how it's stored internally — the number base converter turns that same integer into hex or binary. And when the timestamp shows up buried inside an API response, the JSON formatter makes it easy to spot and count the digits at a glance.

Frequently asked questions

Related tools

• Unix timestamp converter — Epoch to readable date, local or UTC.
• Date calculator — Add, subtract, and diff dates.
• Number base converter — Decimal, hex, binary, and octal.
• JWT decoder — Inspect the exp and iat claims inside a token.

You might also like: what Base64 encoding is, the encoding JWTs use under the hood.