A Unix timestamp is just a count: the number of seconds that have ticked by since 1970-01-01 00:00:00 UTC, a moment called the Unix epoch. It has no time zone, no slashes, no AM/PM — one plain number that every computer can store and compare. Here's what it means, why it starts in 1970, the seconds-versus-milliseconds trap, and the Year 2038 problem.
Right now it is roughly …
…
Type a 10-digit number for seconds or a 13-digit number for milliseconds. Everything is worked out in your browser — nothing is sent anywhere.
Pick any moment in history and a computer can describe it with a single whole number: how many seconds it sits after the epoch. The epoch is the agreed "zero" — 0 is exactly midnight UTC at the start of 1 January 1970. Every second since then adds one. So a timestamp like 1700000000 means "1.7 billion seconds after that midnight," which works out to 14 November 2023.
Because it's only a count, it carries none of the messiness of human calendars — no months of different lengths, no leap-year branching, no AM/PM, no "is that 04/03 March or April?" A timestamp is the same number whether you're in Tokyo or Lima; only when you display it does a time zone get added. That simplicity is exactly why it's the timekeeping that runs underneath almost everything: file dates, databases, log lines, web cookies and API responses are full of these numbers.
There's nothing magical about the date. When the Unix operating system was being built at Bell Labs around 1970, its designers needed a fixed reference moment to count from, and a clean, round, recent date was the obvious pick. They landed on the first second of 1970. Every Unix-descended system — Linux, macOS, Android, iOS and the servers behind most websites — has counted from that same instant ever since, which is why the format is sometimes called POSIX time or epoch time.
This is the single most common mix-up. Two units are in everyday use:
1700000000). Used by databases, spreadsheets, command-line tools and most back-end code.1700000000000). This is what JavaScript (Date.now()) and most web APIs hand you.If a converter throws back a date in the year 54000 or back in 1970, you almost certainly fed it the wrong unit. The fix is a single step: divide milliseconds by 1000 to get seconds, or multiply the other way. The converter at the top of this page guesses the unit from the length of the number for you.
You can roughly place a timestamp in history just from how big it is. These are real milestones, all in UTC:
| Timestamp (seconds) | Moment in time |
|---|---|
| 0 | 1 Jan 1970 |
| 1,000,000,000 | 9 Sep 2001 |
| 1,500,000,000 | 14 Jul 2017 |
| 1,700,000,000 | 14 Nov 2023 |
| 2,000,000,000 | 18 May 2033 |
| 2,147,483,647 | 19 Jan 2038 — the 32-bit limit |
| 4,294,967,295 | 7 Feb 2106 |
A "ten-digit number starting with 17…" is a date in the early-to-mid 2020s. The crossing to 2,000,000,000 happens in 2033.
A Unix timestamp has no time zone baked in — it is fixed to UTC, the world's reference clock. The same number 1700000000 is 14 Nov 2023 at 22:13:20 in London (winter, on UTC), but 17:13:20 the same day in New York and 07:13:20 on the 15th in Sydney. The instant is identical everywhere; only the wall-clock label changes when each region applies its own offset. That's the whole appeal: store one neutral number, and let every device translate it to local time when it shows it to a person.
For decades, many systems stored the timestamp in a signed 32-bit number. That can only count as high as 2,147,483,647 — and the clock reaches exactly that value at 03:14:07 UTC on 19 January 2038. One second later the counter overflows and wraps around to a large negative number, which reads back as December 1901. It's the same shape of bug as the Year 2000 scare, just with a different ceiling.
The fix is already widespread: modern systems use 64-bit timestamps, which raise the limit to roughly 292 billion years from now — comfortably past any deadline that matters. Most current phones, servers and operating systems are already 64-bit clean; the lingering risk is in old embedded hardware that's hard to update.
Occasionally the world's official timekeepers add a leap second to keep atomic clocks aligned with the Earth's slightly irregular spin. Unix time pretends these don't exist — it always treats a day as exactly 86,400 seconds. When a leap second happens, the count simply repeats or stretches a second so the books stay even. It's a small white lie that keeps the arithmetic clean: you can always divide a Unix timestamp by 86,400 to get whole days, which ties straight into the units-of-time maths.
A single number: the count of seconds since midnight UTC on 1 January 1970, the Unix epoch. It has no time zone or calendar attached, which makes it a simple, unambiguous way for computers to store and compare moments.
It was a convenient, round, recent date when Unix was built at Bell Labs around 1970. Nothing about the date is special — it just had to be a fixed "zero" everyone could agree on.
Ten digits is seconds since 1970; thirteen digits is milliseconds (a thousand times bigger). Databases and command-line tools use seconds; JavaScript and the web use milliseconds. A wildly wrong date usually means the wrong unit — divide or multiply by 1000.
Old 32-bit systems can only count to 2,147,483,647 seconds, which is reached at 03:14:07 UTC on 19 January 2038. After that the counter overflows. Modern 64-bit systems push the limit billions of years out, so it's fixed almost everywhere already.
The live timestamp and converter above run entirely in your browser — nothing you type is sent anywhere. For everyday date maths, the week.hako.to calculators handle days between dates, countdowns and ISO week numbers, all locally.