Loading…
Convert a Unix timestamp to ISO 8601, UTC, local time, and RFC 2822 — or a date back to epoch seconds. Seconds, milliseconds, and microseconds are detected automatically.
Accepts ISO 8601, RFC 2822, and plain calendar dates. A date without a zone offset is read as UTC.
This Unix timestamp converter turns an epoch number into every representation you are likely to need — ISO 8601, a readable UTC string, the same instant in your own time zone, RFC 2822, and a plain-English "3 hours ago" — and converts back the other way from a date string into epoch seconds and milliseconds. Paste a value from a log line, a database column, or a JWT claim and you can read it immediately instead of squinting at ten digits and guessing which decade they land in.
The awkward part of epoch values is that the number alone does not say what precision it is in. `1516239022` is seconds, `1516239022000` is milliseconds, and `1516239022000000` is microseconds, but they all describe the same moment — and misreading one as the other throws you off by a factor of a thousand, which is how a 2018 event ends up rendered as the year 50,000. This tool infers the unit from the magnitude of the number, shows you which one it picked, and lets you override that guess when the heuristic is wrong or you simply want to check what the other reading would be.
Everything runs locally in your browser, which matters more than it sounds: local-time output depends on your machine's time zone, and relative phrasing depends on your clock, so both are computed on your device rather than on a server sitting in some other region. Timestamps you paste are never uploaded or stored. If a result looks a day off, the usual culprit is a system clock or a time zone assumption rather than the conversion — compare the UTC and local rows, which always describe the same instant, and the difference between them will tell you which one you were actually looking at.
Count the digits. A present-day timestamp in seconds is 10 digits, in milliseconds 13, and in microseconds 16, and those ranges stay distinct for thousands of years, which is what makes auto-detection reliable. As a rule of thumb, Unix tooling and JWT claims use seconds, while JavaScript's Date.now(), Java, and most JSON APIs use milliseconds.
The Unix epoch is 00:00:00 UTC on 1 January 1970, the zero point that Unix timestamps count from. A positive timestamp is that many seconds after the epoch; a negative one is that many seconds before it, so dates prior to 1970 are represented perfectly well as negative numbers. The epoch is always anchored to UTC, never to a local time zone.
Systems that store a timestamp in a signed 32-bit integer run out of room at 03:14:07 UTC on 19 January 2038, at which point the counter overflows and wraps around to 1901. Modern platforms use 64-bit timestamps and are unaffected, but embedded devices, old file formats, and legacy database columns can still be vulnerable — which is why it is worth checking the width of any integer column you store epochs in.
They are the same instant described from two vantage points. UTC is the absolute reference, while the local row applies your machine's time zone and daylight saving rules, so the two can differ by hours and even fall on different calendar dates. When you store or compare timestamps, keep them in UTC and convert to local only for display.
No, and that is deliberate. Unix time defines every day as exactly 86,400 seconds, so a leap second is not given its own value — it is absorbed, typically by repeating or smearing a second. This keeps arithmetic simple at the cost of Unix time drifting from true astronomical time by a few dozen seconds. If you need genuine leap-second accuracy you need TAI, not Unix time.