NNonkera
Developer ToolsUpdated July 31, 2026

What Is Unix Time (Epoch Time) and How Do You Convert It?

What Unix timestamps actually represent, why systems use them instead of formatted dates, and the seconds-vs-milliseconds mix-up that causes the most confusion.

The basic definition

Unix time counts the number of seconds that have elapsed since midnight UTC on January 1, 1970 — a fixed reference point called the Unix epoch. Instead of storing a moment as a year, month, day, hour, minute, and second, systems that use Unix time store it as one single, ever-increasing number, which is simpler to store, compare, and do math on than a formatted date string.

Why systems prefer a single number over a formatted date

A formatted date is genuinely ambiguous without extra context — is 03/04/2026 March 4th (US convention) or April 3rd (most of the rest of the world)? A Unix timestamp has no such ambiguity: it's one specific, unambiguous number that means exactly one moment in time, universally, regardless of the reader's local date-formatting convention. It's also trivial to calculate a duration between two timestamps (just subtract) or check chronological order (just compare), operations that are notably fiddlier with formatted date strings.

Seconds vs. milliseconds: the most common mix-up

Traditional Unix/POSIX systems and most server-side APIs count in seconds, but JavaScript's own Date.now() and many web APIs count in milliseconds — a thousand times more granular. Treating a millisecond timestamp as though it were seconds (or vice versa) is one of the most common timestamp bugs: a millisecond value misread as seconds resolves to a date tens of thousands of years in the future, which is usually the immediate giveaway that the unit was mixed up somewhere in the pipeline.

Local time vs. UTC when converting

A Unix timestamp itself has no time zone attached — it's a single, global count. Converting it into a readable date requires choosing a time zone to display it in, and mixing up local time and UTC is a second common source of confusion, since a timestamp that looks "wrong" is often just displayed in the wrong time zone rather than actually incorrect. Server logs and API documentation are conventionally in UTC, so it's worth checking both when debugging a timestamp that doesn't match what you expected.

Frequently asked questions

What date does a Unix timestamp of 0 represent?

Midnight UTC on January 1, 1970 — the fixed reference point Unix time counts forward from.

Is a Unix timestamp in seconds or milliseconds?

It depends on the system — traditional Unix time and most APIs use seconds, while JavaScript and many web APIs use milliseconds. Check which one a given system expects.

Does a Unix timestamp include a time zone?

No — it's a single, time-zone-independent number. The time zone only matters when converting it into a human-readable date.

Why would a converted date show a year like 51,234?

That's the classic sign of a seconds-vs-milliseconds mix-up — a millisecond value interpreted as seconds resolves to a date tens of thousands of years too far in the future.

Why do systems use Unix time instead of formatted dates?

It's unambiguous across locales, and simple to compare or calculate durations with, unlike formatted date strings which vary by convention and require parsing before they can be compared.