Unix Epoch Time Explained (and Why It Starts in 1970)

Open a database row, a server log, or a JSON payload from almost any API, and somewhere you'll find a timestamp that looks like 1735689600 — a bare, unlabeled integer with no year, month, or colon in sight. That number is Unix time: a running count of seconds since one fixed moment, chosen more than fifty years ago, that quietly underpins how nearly every computer on Earth keeps track of "when."

This piece is specifically about that fixed moment — the epoch itself: what the word means, why it lands on 1 January 1970, how the count behaves at its edges, and where it breaks. For the mechanics of turning a specific timestamp into a calendar date, the conversion guide covers that step by step; for the broader shape of a Unix timestamp as a data type, see what a Unix timestamp is.

In everyday English, an "epoch" is a long stretch of history. In computing, the word means something narrower and much more precise: a single reference point in time, fixed by convention, from which a system measures every other moment as an offset. It isn't a duration — it's a marker, the "zero" on a number line that runs in both directions.

Unix time is only one epoch among several used in computing (more on the others below), but it's by far the most common, because it underlies POSIX — the specification that most Unix-like operating systems, and the languages built on top of them, implement. When a system says a file was modified at timestamp 0, it means exactly one thing: the epoch itself, with zero seconds added.

There's no event of historical significance tied to 00:00:00 UTC on 1 January 1970 — nothing happened that day that made it worth immortalizing. The date was a practical decision made by the engineers building Unix at Bell Labs in the early 1970s, and by most accounts it came down to convenience: it was a recent, round date at a time when memory was scarce and every bit used to store a time value was a bit that couldn't be used for something else. Starting the count near the present, rather than at some earlier "meaningful" year, kept the numbers smaller for longer.

It also wasn't the operating system's original choice. Early Unix measured time in 60ths of a second using a 32-bit unsigned counter, which could only span roughly two and a half years before wrapping around — so the reference point had to sit close to the present just to avoid immediate overflow. Once Unix moved to counting whole seconds instead, that constraint eased, and the epoch settled on 1 January 1970, a choice first written down in the Unix Programmer's Manual in the early 1970s and never revisited since.

A Unix timestamp is the number of seconds that have elapsed since the epoch, and the arithmetic is deliberately simple: every real second that passes, the count goes up by exactly one. There's no month length to account for, no leap year to check, no time zone offset to apply — that's the entire point of representing time this way. Comparing two moments, or measuring a duration, becomes a single subtraction between two integers instead of calendar math.

Underneath that simplicity sits one quiet approximation: POSIX defines the relationship between a calendar date and its epoch seconds by assuming every day is exactly 86,400 seconds long. In reality, the length of a day drifts very slightly, and every so often a leap second is inserted into UTC to keep clocks aligned with the Earth's rotation. Unix time doesn't count those extra seconds — when a leap second occurs, most systems either repeat a second or smear it across the surrounding time, rather than letting the epoch count tick past what the formula expects. The practical effect for most software is negligible, but it means Unix time is a simplified, calendar-derived count rather than a literal tally of physical seconds.

Seeing the number move helps it click. Below is the Unix timestamp for this exact moment, ticking up by one every second, alongside the UTC date and time it corresponds to.

Because the epoch is just a reference point and not a "beginning," the count is allowed to run backward. A negative Unix timestamp — something like -86400, one full day before the epoch — represents a valid date before 1 January 1970. Subtracting seconds from zero works exactly the same way as adding them, so timestamps for historical dates, birth years before 1970, or any pre-epoch record can be stored as ordinary negative integers.

In practice, support is uneven. Many programming languages and database engines handle negative epoch values correctly, but plenty of tools, embedded devices, and older APIs were only ever tested against positive timestamps and will reject or mishandle a negative one. If a system needs to represent dates well before 1970 — genealogical records, for instance — it's worth checking that negative timestamps are actually supported rather than assuming they are.

The epoch itself never changes, but the unit used to count from it does, and mixing them up is one of the most common bugs involving timestamps. Most Unix system calls, Python's time.time(), and Ruby return epoch seconds — a 10-digit number in the current era. JavaScript's Date.now() and Java's System.currentTimeMillis() return epoch milliseconds instead — a 13-digit number, exactly 1,000 times larger for the same instant. Some logging and analytics systems go further and use microseconds or nanoseconds.

The tell is the number of digits. As of 2026, a correct epoch-seconds value is 10 digits long; an epoch-milliseconds value for the same moment is 13 digits. A date that computes to sometime in the year 50,000, or to 1970 when it should be recent, is almost always a units mismatch — a seconds value read as milliseconds, or vice versa — not a genuine bug in the epoch logic itself. For millisecond-specific handling, see milliseconds to time.

Storing a growing count of seconds requires a data type with a finite size, and the type chosen by many historical systems — a signed 32-bit integer — can only represent whole numbers up to 2,147,483,647. Counting seconds from the 1970 epoch, that ceiling is reached at 03:14:07 UTC on 19 January 2038. One second later, the value overflows and wraps around to a large negative number, which an unpatched 32-bit system reads back not as an error but as a specific, wrong date: 13 December 1901.

This is the Year 2038 problem, and it's a direct consequence of the storage format, not the epoch concept itself — the fix is switching the underlying time type from a 32-bit to a 64-bit integer, which pushes the next overflow roughly 292 billion years into the future. Most current 64-bit operating systems and modern language runtimes have already made this switch; the remaining risk sits in older embedded systems, legacy databases, and file formats that still store time in 32 bits and are harder to update.

Unix time is the most widely used epoch, but it isn't the only one. Other platforms picked their own zero points, for their own reasons, and none of them convert to Unix time by a simple offset unless you know the exact rule.

Windows' 1601 start date is its own small piece of trivia: it's the beginning of the 400-year Gregorian calendar cycle that includes 1970, chosen so the math for leap years repeats cleanly. When timestamps from two different systems need to be compared, the safest approach is to convert both into calendar date and time first — using each system's stated epoch and unit — rather than assuming the raw numbers share a scale.

Epoch timestamps show up anywhere a system needs to store "when" compactly and compare it cheaply: database created_at and updated_at columns, HTTP cache headers, JWT expiry fields, log lines, file metadata, and the internals of almost every date library. They're popular precisely because a single integer sorts, compares, and stores more efficiently than a structured date, and because they sidestep time zones entirely until the moment something needs to be displayed to a person.

That last part matters for formatting, too: once you have an epoch value and want to hand it to a reader, it eventually needs to become a calendar date, and often a 12-hour or 24-hour clock time and even a standardized text format like ISO 8601. Scheduled jobs are the other common meeting point — a cron expression describes when a task should run in calendar terms, but the system checking "is it time yet" is usually comparing against the current epoch value underneath.