Unix timestamp to date and back, seconds or milliseconds, with a live clock.
A bare number like 1718600000 in a log means nothing until you convert it, and that's the whole job here. Paste it and we work out whether it's seconds or milliseconds (the usual trap, off by a factor of a thousand), then show the local time, the UTC time, the ISO string and how long ago that was. The live clock up top keeps the current timestamp handy, and the date picker runs it the other way when you need a timestamp from a calendar date. We built it for the moment an API hands you an integer and you just need to know what instant it points at. It all runs in your browser, nothing leaves the page.
100% in your browser. Nothing you type ever leaves this page.
...s
...ms
- Local time
- ...
- UTC
- ...
- ISO 8601
- ...
- Relative
- ...
...
A timestamp is just a count of seconds
Unix time counts the seconds since midnight UTC on 1 January 1970. One integer, no time zone attached, identical everywhere on Earth at a given instant. That’s exactly why it turns up in logs and API payloads, and also why it stops people the first time they meet it, because a number like 1788393600 tells you nothing at all until something converts it.
Paste it above and you’ll get the date. Paste a date and you’ll get the number back. The reverse direction matters more than people expect, since half the time you’re not decoding a log line, you’re building a query and need the boundary of "everything after last Tuesday" as an integer.
One date worth having in your head: the signed 32 bit version of this counter runs out on 19 January 2038. Anything still storing a timestamp in a 32 bit signed integer wraps to 1901 that morning. Most modern systems moved to 64 bits years ago, embedded firmware very much didn’t, and 2038 is closer than 1970 now.
Seconds, milliseconds, and the two nobody warns you about
This is the trap, and it’s silent. JavaScript, Java and plenty of APIs count in milliseconds. Unix tools, most databases and most backends count in seconds. Same instant, factor of a thousand apart. Feed the wrong one into the wrong parser and your date lands in 1970 or somewhere past the year 56000, and nothing errors.
Count the digits. Right now a seconds timestamp is 10 digits, milliseconds is 13, microseconds is 16 and nanoseconds is 19. This tool guesses from the length and tells you which it assumed, so a bad guess is visible rather than silent, and you can flip it by hand when your value isn’t typical.
Two more formats turn up in real logs, and neither one’s Unix time, so a normal converter will produce nonsense from them. Windows FILETIME counts 100 nanosecond intervals since 1 January 1601, which is why those values are eighteen digits and land in the seventeenth century if you treat them as seconds. .NET ticks use the same 100 nanosecond unit but start from the year 1. If a timestamp converts to something wildly historical, the epoch is wrong rather than the number.
Time zones, and why the stored value has none
The local line here uses your browser time zone, which is convenient for a quick read and isn’t what you should persist. A Unix timestamp has no zone. It’s an absolute instant, and the zone only appears when a human looks at it.
So converting to Pacific, Central European or anywhere else is a display step, and the honest way to do it is with a named zone rather than a fixed offset. Pacific time is UTC minus eight in winter and UTC minus seven in summer, so a value hardcoded to minus eight is wrong for eight months of the year. We’ve watched that one survive code review more than once. Use America/Los_Angeles or Europe/Paris and let the zone database handle the switch, because governments change these rules more often than anyone budgets for.
The rule we’d defend anywhere: store the raw timestamp or an ISO string in UTC, convert to local only when rendering. We store epoch seconds and nothing else, and we’ve never once regretted it. Mixing local times into stored data is how you get the bugs that surface twice a year, at two in the morning, on the daylight saving switch, and those are miserable to debug because the data looks fine by the time anyone reads it.
Frequently asked questions
How do I convert an epoch timestamp to a date?
Paste the number above and the date appears in UTC and in your local zone at the same time. It works in both directions, so a date goes back to an integer just as easily. Seconds and milliseconds are detected automatically from the digit count, and the tool shows which it picked so you can correct it if the value is unusual.
Seconds or milliseconds, how can I tell?
By length. A current timestamp in seconds is 10 digits and has been since 2001. Milliseconds is 13, microseconds 16 and nanoseconds 19. If a converted date lands in 1970 you’ve almost certainly handed milliseconds to something expecting seconds. Thousands of years out and you’ve done the reverse.
How do I convert epoch time to PST or another time zone?
Convert to UTC first, which is what the timestamp actually means, then apply the zone as a display step. Do it with a named zone such as America/Los_Angeles rather than a fixed offset, because Pacific time is UTC minus eight in winter and minus seven under daylight saving. A hardcoded offset is quietly wrong for most of the year, and that class of bug tends to survive review.
Why does my timestamp convert to a date in 1601 or the year 1?
Because it’s not Unix time. Windows FILETIME counts 100 nanosecond intervals from 1601 and .NET ticks count the same unit from the year 1, and both are common in logs from those platforms. Neither will make sense in a Unix converter. You can’t convert one of these safely until you know which system produced it.
What happens in 2038?
A signed 32 bit timestamp reaches its maximum on 19 January 2038 at 03:14:07 UTC and wraps to December 1901. Anything on 64 bit storage is fine for longer than we’ll be around to care. The exposure sits in embedded devices, and in database columns that were sized decades ago and never revisited since, which is worth a grep well before the date arrives.