Unix timestamp, ISO date, timezone and batch converter
Paste a Unix number (seconds, milliseconds, micro, whatever) or a readable date, and get back UTC, your local time, ISO 8601, RFC 2822, SQL, plus the same instant across a few timezones. It also chews through a batch of log lines and pulls apart JWT date claims. Mostly it exists so you stop reading a 10-digit number as seconds when it was milliseconds all along. Been there.
Everything runs in your browser. And remember: Unix time sits on UTC. Picking a timezone just changes how it reads, not the actual moment.
Timestamp conversion is really just guessing the unit right
Unix timestamps look harmless. They’re numbers. That’s exactly why they bite. Some systems hand you seconds. JavaScript gives milliseconds. A database might be sitting on microseconds, and some event pipeline somewhere is logging nanoseconds because why not. A 10-digit value and a 13-digit value can be the same instant, if one’s seconds and the other’s milliseconds. Read it in the wrong unit and your date jumps by decades. Honestly that’s the bug I’ve hit most.
So this thing is built for the messy stuff: log debugging, JWT claims, APIs, schedulers, backups, the occasional weird database row. It sniffs out the common digit lengths on its own, but you can also force seconds or milliseconds or micro or nano when you already know. It parses ISO strings, lines UTC up against named zones, tells you how far the moment sits from right now, and dumps a batch of mixed values into CSV you can paste straight into a ticket.
How to read timestamps safely
Figure out the unit first. For modern dates, Unix seconds usually land at 10 digits and milliseconds at 13. Micro and nano are longer, and they’re honestly more precision than a plain JavaScript date wants, so the date you see here leans on the millisecond part. After that, keep storage and display in separate boxes. Store UTC instants. Format them for the human right at the edge, where you show them. And whenever an actual deadline or someone’s calendar is on the line, say the timezone out loud. People forget, then they’re an hour late.
- Unix seconds show up in JWT
exp,nbfandiatclaims. - Unix milliseconds are the JavaScript default, so you’ll see them in browser logs and plenty of APIs.
- ISO 8601 is usually the least painful format to hand between systems.
- Timezone views tell you what one instant actually means in Paris versus UTC versus Tokyo.
- Batch conversion earns its keep mid-incident, when the logs are a soup of mixed formats.
Common timestamp debugging examples
Token dies the second it’s issued? Decode the JWT and run the exp claim as Unix seconds, you probably fed it milliseconds. Cron firing at a weird hour? Line up the server’s timezone against the human one before you touch anything. A log date stuck in 1970 or sitting way out in the future almost always means seconds and milliseconds got swapped somewhere. And when two regions can’t agree on a date, don’t go rewriting application logic yet. Compare the exact same UTC instant in both zones first. Nine times out of ten the data was fine and the display lied.
Common questions
Is Unix time affected by timezone?
Nope. It counts from the UTC epoch, full stop. Timezones only change how that instant gets dressed up for a human to read. The number underneath doesn’t move.
Why do JavaScript timestamps have 13 digits?
Because Date in JavaScript counts milliseconds since the epoch, not seconds. Plenty of APIs use seconds though, and that mismatch is exactly where the off-by-1000 bugs sneak in.
Can I convert nanoseconds exactly?
Sort of. It’ll detect a nanosecond value and scale it down so the date shows up right. But the date itself caps out at millisecond precision, that’s a browser limit, not something I can wish away. The sub-millisecond digits are still in your original number if you need them.
How do I convert a Unix timestamp to a date?
Drop the epoch number in the box up top. It guesses the unit (seconds, milliseconds, micro, nano) and spits back your local time alongside UTC and a clean ISO 8601 string. If the guess looks off, force the unit with the dropdown and convert again.
What is the Unix epoch?
It’s one fixed moment: 00:00:00 UTC, 1 January 1970. Unix time just counts the seconds since then and quietly ignores leap seconds. That’s the whole trick, really. Because it’s a plain monotonic count tied to nothing local, you can store it anywhere and compare it across systems without the timezone mess getting a vote.
What is the year 2038 problem?
Anything still cramming Unix time into a signed 32-bit integer runs out of room on 19 January 2038 and wraps around to a negative date, which looks like 1901. The fix is boring and already done in most places: use a 64-bit value. Modern languages and databases default to that now. The stragglers tend to be old embedded gear nobody wants to touch.
