Unix time: the seconds since 1970

Ask a person the time and they glance at a clock and say something like “quarter past three”. Ask a computer, and underneath whatever it shows on screen it is almost certainly keeping a single whole number instead, the count of seconds that have passed since one fixed moment in history. That moment is called the Unix epoch, and the running total is called Unix time. It carries no time zone, no calendar date in the usual sense, no notion of your morning or someone else’s evening: just seconds, ticking up one at a time. This guide explains where that number comes from, why it is so convenient, where you are likely to bump into it, and the one famous flaw waiting for it in 2038.

The epoch, one moment to count from

Every counter needs a zero. Unix time’s zero is 00:00:00 UTC on 1 January 1970, midnight at the very start of that year, measured in Coordinated Universal Time rather than in any local clock. That instant is the epoch, chosen by the designers of the Unix operating system as a convenient recent starting point. From there the rule could not be simpler: Unix time is the number of seconds that have elapsed since the epoch. A moment ten seconds after that midnight is 10; an hour later is 3,600; and the count climbs by one every second, indefinitely.

Times before 1970 are not off-limits. They are simply negative numbers. A date in 1969 has a Unix time below zero, counting backwards from the epoch. And because the reference point is pinned in UTC, the whole scheme is anchored to a single, unambiguous instant rather than to wherever the computer happens to be sitting.

Why a single number is so convenient

The great virtue of Unix time is that it is time-zone-free. The same instant is the same number everywhere: when a phone in Tokyo and a server in Chicago both record “now”, they record the identical Unix value, even though their wall clocks read hours apart. Local time is not stored at all. It is worked out afterwards, by taking the universal number and adding or subtracting the offset for wherever you want to display it.

That single-number design makes the arithmetic computers do with time almost trivial. Working out how far apart two events were is a subtraction. Sorting a pile of records into the order they happened is sorting a column of integers. Checking whether a login token has expired is comparing one number against another. None of it requires reasoning about zones, calendars, or which month has thirty-one days, all of that complexity is deferred to the single moment when a human needs to read the result. Storing the messy human calendar directly would force every one of those operations to untangle months, leap years and offsets first; storing a plain integer keeps the hard part in one place, at the very edge where the number is turned back into something people recognise.

Unix time buys that tidiness with one deliberate simplification: it treats every day as exactly 86,400 seconds and, by convention, ignores leap seconds, the occasional extra second added to keep official clocks in step with the Earth’s slightly irregular rotation. That keeps the count perfectly regular at the cost of a small, chosen inaccuracy, a trade-off explored in leap seconds explained.

Where you actually meet Unix time

You do not have to be a programmer to have this number pass through your hands. Open a server or application log and the entries are often stamped with Unix time, so that whoever reads them later can line events up precisely regardless of where the machine or the reader happens to be. Ask a web service for data and its response, typically JSON, will frequently give dates as a Unix timestamp rather than a written-out date, leaving the formatting to whatever app receives it. The “modified” date your operating system shows for a file is, underneath, stored this way. And databases lean on it heavily, because a column of integers is cheap to store, quick to sort and unambiguous to compare.

When you do meet a bare timestamp, a long run of digits where you expected a date, you rarely need to decode it by hand. A converter turns it back into a readable date in whatever zone you choose; the Unix timestamp tool on this site does exactly that, in both directions.

The year 2038 problem

There is a catch, and it has a date. For decades many systems stored Unix time in a signed 32-bit integer, a container with room for a little over two billion positive values. That was ample in 1970, but the seconds keep piling up and the ceiling is now in sight. At 03:14:07 UTC on 19 January 2038 that counter reaches its largest possible value. One second later it cannot go any higher, so it wraps around to a large negative number, and a computer that trusts it will abruptly believe the time is somewhere near the start of the twentieth century. This is the “year 2038 problem”, and it is the same species of flaw as the year 2000 bug: not a mistake in the idea, just a box that eventually runs out of room.

The fix is straightforward and already widespread: store the count in a 64-bit integer instead. That raises the ceiling so far into the future that it stops being a practical concern at all. Modern operating systems, programming languages and databases have largely moved to 64-bit time already. The remaining risk lives in older systems and embedded devices that are awkward to update and quietly assume the smaller size, which is why 2038 is worth naming now, rather than rediscovering on the day.