Epoch and timezone converter
Convert a Unix timestamp to a date, or a date to a timestamp, and see the same instant across several timezones at once — with real daylight-saving offsets, not a fixed UTC difference. Runs entirely in your browser.
—
| Format | Value | |
|---|---|---|
| Nothing to convert yet. | ||
| Timezone | Local time | UTC offset |
|---|---|---|
| Nothing to convert yet. | ||
About this tool
Type a Unix timestamp, or a date and time in any timezone, and this page converts between them and shows the result in several common formats plus a table of the same instant across whichever timezones you add. Both directions share one internal representation — a single point in time — so switching between "From epoch" and "From date" never loses precision or drifts.
How it works
A pasted timestamp is auto-detected as seconds or milliseconds: values under 1012 are treated as seconds (that threshold comfortably covers every real seconds-based timestamp — it would only be reached by a seconds value around the year 33,658 — while a genuine millisecond timestamp for any recent or current date is already past it). The detected unit is always shown, and can be overridden if it ever guesses wrong.
Timezone conversion uses the browser's own Intl.DateTimeFormat with each zone's real IANA name, so daylight-saving changes are handled correctly and automatically — the UTC offset shown for each zone is computed for that specific instant, not a fixed value, which is why the same zone can show a different offset for a summer date than a winter one.
RFC 2822 output is built from the same UTC string JavaScript's own Date.prototype.toUTCString() produces, with GMT swapped for +0000 — the two formats describe the same moment, just with a different sign-off convention.
Common questions
Why did my 13-digit number come out in the far future or the 1970s?
A 13-digit number is almost always milliseconds. If auto-detect guessed seconds instead — unlikely, since the threshold is set well above any real seconds timestamp — switch the unit selector to Milliseconds and it will be read correctly either way.
Can this handle dates before 1970?
Yes — negative Unix timestamps are valid and represent dates before 1 January 1970 UTC. They convert exactly the same way as positive ones.
What's the actual range this can represent?
Whatever JavaScript's own Date can hold — plus or minus about 275,760 years from 1970. Nothing outside that range will produce a result.
Known limitations
Leap secondsUnix time does not count them, and neither does this page — the same convention every mainstream system clock, NTP-synced or not, actually uses.Timezone listUsesIntl.supportedValuesOf("timeZone")where the browser supports it, falling back to a short hand-picked list of common zones plus UTC otherwise.Historical offsets before IANA tzdata coverageVery old or unusual dates depend entirely on the accuracy of the browser's own bundled timezone database — this page adds nothing on top of it and cannot correct it.
The same job at the command line
date -d @1755043200 -uGNUdate(Linux): convert a Unix seconds timestamp to a UTC date.date -r 1755043200 -uBSD/macOSdate: the same conversion — GNU and BSDdatetake this flag differently.date -u +%sCurrent Unix seconds timestamp, in UTC.python3 -c "import datetime; print(datetime.datetime.fromtimestamp(1755043200, datetime.timezone.utc))"Python, timezone-aware.node -e "console.log(new Date(1755043200000).toISOString())"Node.js, the exact engine this page's date maths runs on.
More tools
See the whole toolbox — thirty-seven free tools planned, all running in your browser.