What Is Unix Time, Actually?

Unix time (also called epoch time or POSIX time) is a way of representing a specific moment as a single number: the count of seconds that have elapsed since 00:00:00 UTC on January 1, 1970 — a moment programmers call "the epoch." Right now, that number is somewhere north of 1.7 billion and climbing by exactly one every second, regardless of what timezone, calendar, or daylight saving rule anyone happens to be using.

Why January 1, 1970 specifically?

There's no deep significance to the date itself — it was simply a convenient, round reference point chosen by the designers of the original Unix operating system in the early 1970s, close enough to "now" at the time that it didn't waste bits on decades nobody needed to represent. Once early Unix systems and the C programming language standardized on it, virtually every operating system, database, and programming language that followed adopted the same reference point for compatibility, and it's been the de facto standard ever since.

Why store time as a number instead of a date string?

A single integer is unambiguous, timezone-independent, and trivial to do math on. Subtracting two Unix timestamps gives you an exact duration in seconds with no calendar logic involved; sorting a column of them sorts chronologically for free; and there's no risk of the "is this 03/04/2026 March 4th or April 3rd?" ambiguity that plagues written date formats. The tradeoff is that the raw number is meaningless to a human without converting it — nobody can glance at 1770000000 and know what day that is.

Seconds, milliseconds, or something else entirely

This is where a lot of real bugs come from. The original Unix standard counts in whole seconds, but JavaScript's Date.now() and many web APIs return milliseconds since the epoch instead — a value 1,000 times larger. Feed a seconds-based timestamp into a function expecting milliseconds (or vice versa) and you'll get a date somewhere in 1970 or the year 55000, not an error — the value just silently means something completely different. A rough rule of thumb: if a "recent" timestamp is 10 digits long, it's almost certainly seconds; if it's 13 digits, it's almost certainly milliseconds.

The other well-known catch: the Year 2038 problem

Many older systems store Unix time as a signed 32-bit integer, which runs out of room on January 19, 2038 — the count will overflow the same way odometers used to roll over, wrapping back around to a date in December 1901. Modern 64-bit systems don't have this ceiling (their limit is tens of billions of years away), but plenty of embedded systems, old file formats, and legacy databases still use the 32-bit version.

Converting it yourself

You don't need to do the arithmetic by hand — use the Unix Timestamp Converter above to go from a raw timestamp to a readable date (and back) in any timezone, or the Batch Converter if you've got a whole list to process at once.