Timestamp Converter
Convert between Unix seconds/milliseconds, ISO 8601 and local time — with the unit detected for you, and the same instant listed across time zones with each zone offset at that moment.
Seconds or milliseconds — detected automatically
e.g. 2026-08-15T10:00:00Z or 2026-08-15 18:00
| Unix seconds | — | |
| Unix milliseconds | — | |
| ISO 8601 (UTC) | — | |
| ISO 8601 (local) | — | |
| Weekday | — | |
| Relative to now | — |
Across time zones
| Time zone | Local time | UTC offset |
|---|---|---|
| UTC | — | — |
| Asia/Shanghai | — | — |
| Asia/Tokyo | — | — |
| Asia/Singapore | — | — |
| Europe/London | — | — |
| Europe/Berlin | — | — |
| America/New_York | — | — |
| America/Los_Angeles | — | — |
Every conversion happens in the browser; no requests are made.
Three places this usually goes wrong
Seconds versus milliseconds is inferred from the digit count, and the inference is shown rather than assumed: ten digits is seconds (until 2286), thirteen is milliseconds. Feed milliseconds into a field expecting seconds and you land in the year 55000; the other way round drops you near 1970. It is the most common timestamp bug there is, so it is not handled silently here.
The zone table shows the wall-clock reading of one instant in each
zone, together with that zone's real UTC offset at that moment. So daylight saving appears instead of
being averaged away: America/New_York is UTC−05:00 in January and
UTC−04:00 in July, and any table with a hard-coded "−5" is wrong half the year. Add any IANA zone you
like — the whole database is already in your browser.
The "ISO 8601 (local)" row is assembled by hand, because
toISOString() always emits UTC with a Z suffix, and treating that as local
time is its own classic bug. This one carries the real offset, e.g.
2026-08-15T18:00:00+08:00.
No moment-timezone or equivalent: browsers have shipped the full IANA database for years and
Intl.DateTimeFormat can query it. Several hundred kilobytes of rules that
go stale would buy exactly the same answers.