Unix timestamp
Unix timestamp converter: epoch to date and back
At the top, the current timestamp ticking. Below, paste a number and get the date — told whether it was read as seconds, milliseconds, micro or nanoseconds — or pick a date and get the number. All at once in your zone, in UTC and in one you choose.
The timestamps you paste never leave your device: they are converted right here.
Why it matters that none of this is uploaded
A lone timestamp looks harmless, but it rarely arrives alone: what gets pasted is a whole column lifted from a production log, complete with the context of the incident you were debugging, or the exact moment of one specific event for one specific customer. None of that needs to pass through anyone's server to become a date. Here there is nowhere to send it: even the time zone database is the one your browser already carries.
How it works, in 3 steps
-
Paste the number, or pick the date
The two converters face each other and talk: use one and the other catches up on its own.
-
Check the unit
You are told whether it was read as seconds, milliseconds, micro or nanoseconds. If more than one reading is believable, it says so and shows you the others.
-
Read it in three zones
Your zone, UTC and one you choose, each with ISO 8601, RFC 2822 and a readable date, and every format with its own copy button.
What people use it for
-
Reading a logA
1756252800shows up in an error trace and you need to know exactly when that was, and in which zone the server wrote it. - Reviewing a database columnPaste a hundred timestamps and take the converted column back to your spreadsheet, without writing a query.
- Checking when a token expiresA JWT's expiry field is a timestamp in seconds, and knowing whether it has already lapsed is half the debugging.
- Reconciling two systemsYour log is in UTC and the customer's is in their local time. Seeing both together saves an afternoon chasing a two-hour offset.
- Writing the right queryEvery database has its own function and you never remember which. The snippets are ready with your number already in them.
- Preparing test dataYou need the exact timestamp for a specific date to seed a database or pin down a test case.
Seconds or milliseconds: the confusion that brings most people here
It is question number one, and the rule is easy: count the digits. A timestamp in seconds for any date between 2001 and 2286 has ten digits. In milliseconds it has thirteen. If it starts with 17 and has ten, those are seconds and you are in 2025 or 2026.
What matters is that getting it wrong does not fail by a little. Reading seconds as milliseconds leaves you in January 1970; reading milliseconds as seconds sends you to the year 57000. They are errors big enough to spot at a glance… if you remember to look.
Why does the confusion exist at all? History. The Unix timestamp was defined in seconds, and that is what the classic functions return: time() in C and PHP, UNIX_TIMESTAMP() in MySQL, EXTRACT(EPOCH FROM …) in PostgreSQL. JavaScript arrived later and chose milliseconds, so Date.now() has three more digits; Java did the same. And systems measuring fast things — tracing, time-series databases — use microseconds or nanoseconds. Hence the same instant turning up with 10, 13, 16 or 19 digits depending on where it came from.
So this tool does not assume: it tries all four readings, keeps the one that gives a believable date, tells you which it used and, when more than one is possible, warns you and shows the others so you can decide.
What the Unix epoch is
It is the instant everything counts from: midnight on 1 January 1970, UTC. A Unix timestamp is simply the seconds elapsed since then. The date was picked for convenience in the early seventies while Unix was being built: round, and close by.
The virtue of the system is what it does not carry. A timestamp has no time zone, no format and no language: it is a number. The same instant is exactly the same number in Tokyo and in Madrid, and it is only turned into a clock time when a person has to read it. That is why it is the right way to store an instant in a database, and why storing "27/08/2026 10:00" as text always ends in tears.
The year 2038 problem
Many older systems store the timestamp in a signed 32-bit integer, whose maximum value is 2147483647. Read as seconds since 1970, that is 19 January 2038 at 03:14:07 UTC. One second later the counter overflows into the largest negative number, which reads as December 1901.
It is the same class of bug as Y2K, but in binary rather than in two decimal digits. Modern systems use 64 bits, where the counter lasts some 292 billion years, so it mostly affects embedded devices, industrial control and old database columns nobody has migrated. This tool warns you when the timestamp you are looking at goes past that limit, because that is exactly when it is worth remembering.
Three zones at once, and why
The most expensive mistake when debugging with timestamps is not converting wrongly: it is converting correctly in the wrong zone. You look at a log, convert it, see a time that does not match what happened, and spend the afternoon hunting a bug that never existed — when all that was happening is that the server writes in UTC and you were reading your own city's clock.
So the result appears simultaneously in your zone, in UTC and in a third one you choose — usually the server's, or that of the customer who reported the problem. The comparison is immediate and the misunderstanding never happens. If what you need is to plan a meeting across cities rather than debug, the time zone planner does that better.
The reverse conversion — from a date and time in a particular zone to a timestamp — has two cases with an ambiguous answer, and they are stated here rather than hidden: on the night the clocks go forward there is an hour that does not exist, and on the night they go back there is an hour that happens twice, with two different timestamps for the same wall clock. The tool detects both and explains them.
Nanoseconds, where precision is lost in silence
This is a detail many tools get wrong. A nanosecond timestamp for 2026 is about 1.76 × 10¹⁸, and the largest integer JavaScript handles without losing precision ends at 9 × 10¹⁵. Converting it with ordinary arithmetic drops digits with no warning at all, and can shift the result by a whole second: while building this tool we checked it with 1756252800999999999, which rolls into the next second that way.
Here the division uses big-integer arithmetic, which is exact. With one honest caveat: the date shown has millisecond resolution, because that is what the browser's date type represents. Nanoseconds are for reading the instant correctly, not for preserving full precision.
Frequently asked questions
Is my timestamp in seconds or milliseconds?
Count the digits: ten for seconds, thirteen for milliseconds, for any date between 2001 and 2286. Starts with 17 and has ten? Seconds, and you are in 2025 or 2026.
Getting it wrong does not fail by a little: seconds read as milliseconds land in January 1970, and the other way round sends you to the year 57000. So nothing is assumed here: all four readings are tried, the believable one is chosen, and you are told which.
Why do some languages give seconds and others milliseconds?
History. The timestamp was defined in seconds and that is what time() in C and PHP, UNIX_TIMESTAMP() in MySQL and EXTRACT(EPOCH FROM …) in PostgreSQL return.
JavaScript came later and works in milliseconds, so Date.now() has three more digits; Java the same. And tracing or time-series systems use microseconds or nanoseconds. Hence 10, 13, 16 or 19 digits.
What exactly is the Unix epoch?
The instant everything counts from: midnight on 1 January 1970, UTC. A timestamp is the seconds elapsed since then. The date was picked for convenience while Unix was being built.
Its virtue is what it does not carry: no zone, no format, no language. The same instant is the same number in Tokyo and Madrid. That is why it is the right way to store an instant in a database.
What is the year 2038 problem?
Many older systems store the timestamp in a signed 32-bit integer whose maximum is 2147483647: 19 January 2038 at 03:14:07 UTC. A second later the counter overflows and the date jumps to December 1901.
It is Y2K in binary. Modern systems use 64 bits and last 292 billion years, so it mostly affects embedded devices and old columns. The tool warns you when you cross that limit.
Why does the result appear in three zones?
Because the most expensive debugging mistake is not converting wrongly, it is converting correctly in the wrong zone. You see a time that does not fit and spend the afternoon on a bug that is not there.
With your zone, UTC and a third to choose — the server's, the customer's — the comparison is immediate. For planning meetings across cities, use the time zone planner.
Can I trust this for nanoseconds?
For reading the date, yes, and that is not the norm. A nanosecond timestamp for 2026 is 1.76 × 10¹⁸ and JavaScript's safe integer ends at 9 × 10¹⁵: ordinary arithmetic drops digits silently and the result can shift by a whole second.
Here the division uses big-integer arithmetic, which is exact. That said, the date shown has millisecond resolution, because that is what the browser's date type represents.
What if I pick a time that does not exist?
You get told. On the morning the clocks go forward there is an hour that never happens — in Spain, 02:30 on the last Sunday of March. It is detected, flagged, and the time the clock actually jumps to is used instead.
And on the night they go back, one hour happens twice: two timestamps for the same wall clock. That is flagged too — the first is used and you are reminded the other is an hour later.
Is anything I paste sent to a server?
No. Everything is converted in your browser, time zones included — they come from the zone database your browser already ships. No accounts, no database. Load the page, disconnect from the internet and check.