Epoch & Timestamp Converter

What a Unix timestamp is

A count of seconds since midnight UTC on 1 January 1970 — the Unix epoch. It is a single integer with no time zone, no locale and no formatting, which is exactly why it is used everywhere for storing and transmitting instants.

That absence of a time zone is the property that makes it valuable. A timestamp means the same moment everywhere on earth; a string like "3/4/2024 9:00" means at least two different days depending on where the reader is and cannot be compared or sorted reliably.

The date 1 January 1970 is arbitrary — it was chosen for convenience by early Unix implementers — and timestamps before it are simply negative.

Seconds or milliseconds: the bug that keeps happening

Unix time is defined in seconds, but JavaScript's `Date.now()` returns milliseconds, as do Java and several other platforms. Mixing the two is probably the single most common date bug in software.

The symptoms are unmistakable once you know them. Treating milliseconds as seconds lands you around the year 56,000. Treating seconds as milliseconds lands you in January 1970. A date wildly wrong in one of those two directions is a units mismatch, not a data problem.

The quick check is digit count. A ten-digit number is seconds and covers 2001 to 2286. A thirteen-digit number is milliseconds. Anything else deserves a second look — a nine-digit value is a date in the 1970s or 80s, which is occasionally legitimate and usually a mistake.

The unit selector here lets you flip between interpretations instantly, which is normally enough to identify what you are looking at.

The 2038 problem

Systems storing Unix time in a signed 32-bit integer overflow on 19 January 2038, at which point the value wraps to a large negative number and the date becomes December 1901. This is a genuine issue in embedded systems, older databases and legacy file formats, not a curiosity.

Modern platforms use 64-bit values, which push the limit hundreds of billions of years out. But 32-bit timestamps persist in older C code, some embedded firmware, certain filesystem formats and a surprising amount of financial and industrial software.

It is worth knowing about when choosing a column type: a 32-bit integer for a timestamp is a decision with a fixed expiry date, and dates beyond 2038 already occur in ordinary business data — thirty-year mortgages, long leases and pension projections all cross it.

The formats shown, and when to use which

ISO 8601 in UTC — `2024-03-15T10:30:00.000Z` — is the right choice for APIs, logs and anything machine-read. It sorts correctly as a string, has no ambiguity, and is parsed by every language.

The UTC string is the same instant in a form humans read more easily. Local time applies your browser's zone and locale, which is what you show a user and never what you store.

The relative format — "3 hours ago", "in 2 days" — is what interfaces display, and it is derived rather than stored. Store the timestamp, format at display time.

One last caution: leap seconds. Unix time deliberately ignores them, so it does not count the true number of elapsed SI seconds since 1970. For everything short of precision timing that is irrelevant, but it is why Unix time is not a strictly monotonic count of physical seconds.