What Unix time is, and what it is not

By Niraj Kumar · Published October 28, 2026

Open a log file, an API response or a database and sooner or later a ten-digit number such as 1793491200 appears where a date should be. That is Unix time: the number of seconds that have elapsed since 00:00:00 on 1 January 1970, Coordinated Universal Time. The instant itself is called the epoch. The number above is 00:00 UTC on 1 November 2026. Paste any such number into the Unix time converter and it becomes a readable date in your own zone.

Why 1970

There is nothing astronomical about the date. Unix was written at Bell Labs at the end of the 1960s, and the first versions counted time in sixtieths of a second from the start of 1971, which overflowed a 32-bit counter in a little over two years. When the count was changed to whole seconds, the start was moved back to a round date, and 1 January 1970 was the nearest. It has stayed put because so much depends on it. POSIX later wrote the definition into the standard that every Unix-like system follows, which is why Linux, macOS, Android, iOS and nearly every programming language agree on the same zero.

The same number everywhere

The most useful property of a Unix timestamp is that it carries no time zone. At the moment the count reached one billion, it was 01:46:40 UTC on 9 September 2001; it was also 21:46 the previous evening in New York and 10:46 in Tokyo, but the number was 1,000,000,000 in all three places. A timestamp describes an instant, not a wall clock. That is exactly what you want when two servers on different continents need to agree on which of two events came first, and it is why a timestamp in a log is more trustworthy than a local date string next to it.

The flip side is that a timestamp tells you nothing about what the clock on the wall said. To show a person the time, you need a zone as well, which is the job the time zone converter does and the reason the Unix time tool asks which zone to display in.

Seconds, milliseconds, and the rest

The original count is in seconds, and a seconds value today has ten digits. JavaScript’s Date.now(), Java’s System.currentTimeMillis() and most message queues count milliseconds instead, giving thirteen digits. Some databases and Go’s UnixNano() go to microseconds (sixteen digits) or nanoseconds (nineteen). The counts differ by exact powers of a thousand, so the mistake to watch for is treating one as the other: a milliseconds value read as seconds lands in the year 58,000 or so, and a seconds value read as milliseconds lands within three weeks of 1970. If a date comes out absurdly far from today, check the units before anything else.

Negative numbers and dates before 1970

Nothing stops the count going below zero. −1 is the last second of 1969, and a date of birth in 1955 is around −450,000,000. Most languages handle negative timestamps correctly, but some older APIs, and a few file formats, treat the value as unsigned and either refuse dates before the epoch or wrap them round to the year 2106. If a system cannot store a birthday before 1970, this is usually why.

Leap seconds are ignored

Here is the part that surprises people. UTC occasionally inserts a leap second to keep civil time aligned with the Earth’s rotation; 27 have been added since 1972, the last at the end of 2016. Unix time does not count them. Every day is exactly 86,400 seconds long in Unix time, so when a leap second occurs the count either repeats a value or runs very slightly slow for a while, depending on how the operating system chooses to smear it. The practical consequence is that Unix time is not quite the number of real seconds since 1970; it is 27 fewer. For almost every purpose that does not matter, and it keeps the arithmetic simple: converting between a timestamp and a calendar date needs no table of leap seconds, which is why the conversion can be done in your browser with no data at all.

Converting by hand

It is worth being able to sanity-check a timestamp without a tool. There are 86,400 seconds in a day and roughly 31.56 million in a year, so dividing a ten-digit value by 31,557,600 and adding 1970 gives the year to within a few weeks. A value starting with 17 is in the mid-2020s; one starting with 16 is around 2020; 15 is 2017 or so. Round numbers are landmarks: 1,500,000,000 was 14 July 2017, and 2,000,000,000 will be 18 May 2033.

Where the count runs out

A signed 32-bit integer tops out at 2,147,483,647, and the count reaches that at 03:14:07 UTC on 19 January 2038. Systems still storing time in 32 bits will then wrap round to a negative value and believe it is December 1901. Modern operating systems use 64 bits, which lasts for about 292 billion years, but the problem lingers in embedded devices, old file formats and database columns. The year 2038 guide goes through where it still bites.

Reading timestamps in practice

Three habits save most of the trouble. Treat a bare number as UTC until something proves otherwise; the display zone is a presentation choice, not part of the data. Check the magnitude for units before trusting a date. And when writing a timestamp for a person to read, convert it once, at the edge, into a format with an explicit offset such as 2026-11-01T00:00:00Z, so that nobody downstream has to guess which zone it was meant in. The time format converter and the guide to ISO 8601 cover the readable end of that exchange.