Unix Timestamps Explained: Why Computers Count Time in Seconds

//: # ()

Need to convert a timestamp right now? Use our free Unix Timestamp Converter — epoch to human-readable and back, with a live ticking clock, entirely in your browser.

What "Unix time" actually is

A Unix timestamp is a single number: the count of seconds that have elapsed since 00:00:00 UTC on January 1st, 1970 — a moment known as the Unix epoch. Right now, that number is roughly 1.79 billion and climbing by one every second. Every programming language, database, and log file that stores "when did this happen" in a compact form is, underneath, almost certainly storing this number.

1700000000  →  Tuesday, November 14, 2023, 22:13:20 UTC

Why not just store a date string?

A handful of very practical reasons this became the default representation computers use internally:

It's a single integer, not a formatted string — comparing "is A before B" is just a < b, no date-parsing logic required, no locale ambiguity (is 03/04/2024 March 4th or April 3rd?).
It's timezone-free — the number itself doesn't care what timezone you're in. Formatting it for a human to read is a separate, later step, done at display time. This is the single most common source of timestamp bugs: storing a formatted local time string instead of a raw instant, then losing the ability to know what that time actually was in UTC.
It's compact — a 4- or 8-byte integer versus a 20+ byte string.
Arithmetic is trivial — "how many seconds between these two events" is just subtraction.

Seconds vs. milliseconds

This is the single most common source of off-by-1000 bugs. Unix time is defined in seconds, and that's what you'll get from most system-level APIs (date +%s in a shell, Python's time.time() returns a float of seconds). But JavaScript's Date.now() and new Date().getTime() return milliseconds — a JavaScript-specific convention, not a platform-wide standard. Mix the two up, and you'll either get a date near 1970 (treating milliseconds as seconds) or a date thousands of years in the future (treating seconds as milliseconds).

A quick sanity check: 10-digit numbers are (currently) seconds; 13-digit numbers are milliseconds.

The Year 2038 problem

Many older systems store Unix time as a signed 32-bit integer. That format runs out of room at 2,147,483,647 — which corresponds to 03:14:07 UTC on January 19, 2038. After that instant, a naive 32-bit signed timestamp overflows and wraps around to a negative number, which typically gets interpreted as a date in December 1901. This is a real, still-not-fully-resolved problem for embedded systems, older filesystems, and legacy 32-bit software — modern 64-bit systems use a 64-bit timestamp, which pushes the equivalent overflow date out roughly 292 billion years, effectively solving it for good.

Unix time vs. ISO 8601

Where a raw epoch number is great for storage and computation, it's useless for humans to read or for two systems to unambiguously exchange a specific date string. That's what ISO 8601 is for — a standardized, sortable, unambiguous text format:

2023-11-14T22:13:20.000Z

The trailing Z means UTC. This is the format you should default to any time you need a timestamp as readable text — in logs, in API responses, in config files — rather than inventing your own date format or relying on a locale-dependent one.

Try it

Convert between epoch seconds, epoch milliseconds, ISO 8601, and local human-readable time with the Unix Timestamp Converter — including a live-updating current timestamp you can copy with one click.