Almost every timestamp you have ever seen in a log file, a database row, or an API response is, underneath, the same thing: a count of seconds. time is the number of seconds that have elapsed since 1970-01-01T00:00:00Z, a moment known as the epoch.

One number, no time zone

The defining feature of Unix time is that it is a single integer with no time zone attached. The instant "1700000000" is the same instant everywhere on Earth; it is only when you want to display it to a human that a time zone enters the picture. That property is exactly why it is so widely used: two systems on opposite sides of the world can compare, sort, and store timestamps without ever negotiating a zone. A larger number is always later; subtraction gives a duration in seconds.

Before the epoch

Time did not begin in 1970, so Unix time simply goes negative for earlier moments. -86400 is exactly one day before the epoch, 1969-12-31T00:00:00Z. Most systems handle negative timestamps cleanly, though some older code assumed time was unsigned and breaks before 1970.

Converting to a date is arithmetic

Turning a Unix timestamp into a calendar date needs no clock and no network: it is pure arithmetic over the proleptic Gregorian calendar. You divide and modulo your way from seconds to days, account for leap years, and arrive at a year, month, day, and time. Because the rules are fixed, the same timestamp always yields the same date, which is what lets a converter like this one run entirely in your browser and produce identical output every time.

Why it won

Unix time beat the alternatives for boringly practical reasons: it is compact (one number), trivially comparable, lexically irrelevant (no string parsing to compare two instants), and unambiguous (no "is this 3 PM in London or Tokyo?"). The cost is that the raw number is unreadable to humans (1700000000 means nothing at a glance), which is the entire reason date formats and converters exist.

Two subtleties are worth knowing before you trust a raw timestamp: which unit it is in (seconds, milliseconds, or smaller), and the fact that Unix time quietly ignores leap seconds. Both have their own articles.

This series, in order

This article opens the series Time as computers count it. The integer above is where every timestamp starts; the parts follow it outwards: the units it hides, the leap seconds it skips, the year a 32-bit counter runs out, the text formats it is written in, and the arithmetic that time zones make dishonest.

  1. Seconds, Milliseconds, Microseconds, Nanoseconds: Telling Epoch Units Apart. Seconds, milliseconds, microseconds or nanoseconds: how to tell them apart from the size of the number.
  2. Why Unix Time Ignores Leap Seconds. Why Unix time pretends every day has 86,400 seconds, and why that is the right trade for civil time.
  3. The Year 2038 Problem. The second a signed 32-bit counter overflows, 2038-01-19T03:14:07Z, and why the fix is simply a wider integer.
  4. ISO 8601, RFC 3339, and the HTTP Date. The broad standard, its strict internet profile and the HTTP date, the formats a timestamp is written back in.
  5. Time Arithmetic and Time Zones: Exact Durations, Honest Meetings. Why plus one month has no exact answer, what ISO 8601 durations promise, and the daylight saving trap.