A Unix timestamp is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, a moment known as the Unix epoch. The start of 31 October 2026 in UTC, for example, is 1793404800. Every computer, wherever it is, agrees on that number for that instant, which is exactly why it's so useful.
Why a single number?
A date written as "31/10/2026 9:00" needs a time zone, a calendar and a date format to be understood, and each of those can be ambiguous. A timestamp needs none of them. It identifies one instant, the same everywhere. Comparing two times is simple subtraction, sorting is trivial, and storing it takes a few bytes. Time zones only come in at the very end, when the number is converted into a local date for a person to read.
That's also the cleanest way to think about it: a timestamp is the instant; the time zone is just the presentation. The same timestamp shows as 05:00 in New York and 10:00 in London during winter, and both are correct.
Why 1970?
There's nothing astronomical about it. The Unix operating system was developed at Bell Labs around 1969–1971, and its designers needed a recent, round starting point. After some early versions used other epochs, 1 January 1970 stuck and became the convention almost everywhere, from databases to phone operating systems to web browsers.
Dates before 1970 are simply negative numbers. Midnight UTC on 1 January 1969 is −31536000.
Seconds or milliseconds?
The classic Unix timestamp counts seconds. JavaScript, Java and many web APIs count milliseconds instead, which makes the number a thousand times bigger. The easy tell is length: for any date between 2001 and 2286, a seconds timestamp has 10 digits and a milliseconds timestamp has 13.
Mixing them up is one of the most common date bugs. Treat a milliseconds value as seconds and you get a date tens of thousands of years in the future; treat seconds as milliseconds and you land a few weeks after 1 January 1970. If a converted date comes out as January 1970, that's almost always the cause. The Unix timestamp converter detects which unit you've pasted automatically.
Some systems go further, to microseconds (16 digits) or nanoseconds (19 digits), mostly for logs and high-precision measurement.
Unix time and leap seconds
Since 1972, 27 leap seconds have been added to UTC to keep it in step with the Earth's slightly irregular rotation, most recently at the end of 2016. Unix time ignores them. It pretends every day has exactly 86,400 seconds, so on the rare occasions a leap second is inserted, the Unix clock either repeats a second or is gently smeared across a longer period, depending on the system.
For almost everyone this doesn't matter, and it has a big advantage: any day's start can be calculated by multiplying the number of days since 1970 by 86,400. In 2022, the international body responsible for the definition of UTC voted to stop adding leap seconds by 2035, which will remove the issue going forward. The leap year guide explains how leap seconds differ from leap days.
The year 2038 problem
Many older systems stored Unix time as a signed 32-bit integer, which can't go higher than 2,147,483,647. That value corresponds to 03:14:07 UTC on 19 January 2038. One second later, a 32-bit counter overflows to a large negative number, and software reading it will think the date is in December 1901.
Modern operating systems, languages and databases have moved to 64-bit time values, which won't overflow for billions of years, so most everyday software is already safe. The risk is in older embedded devices, file formats and databases with 32-bit fields, which is why it's still a known item on engineering checklists.
Reading and writing timestamps
- Store and transmit in UTC (or as timestamps), and convert to local time only for display.
- When you need a human-readable form in data, use ISO 8601 with an offset, such as
2026-10-31T09:00:00-04:00or2026-10-31T13:00:00Z. It sorts correctly as text and leaves no doubt about the zone. - Don't store a local time without its zone. "2026-11-01 01:30" in New York happened twice that night, once before and once after the clocks went back. The daylight saving guide explains the repeated hour.