unix · ISO · time zones
Time converter
Paste a Unix timestamp or an ISO 8601 date and read that one instant in UTC, in the zone you pick and in the zones you watch. The offset arithmetic runs in this tab.
A bare number is read by its length: exactly 10 digits are seconds, exactly 13 are milliseconds, and any other length is refused rather than guessed. An ISO date without an offset is read as UTC, because you meant one instant, not one per zone.
How to convert a timestamp
Enter the instant
Paste a 10-digit Unix timestamp, a 13-digit millisecond one, or an ISO date such as 2026-09-12T14:30:00Z — or type now to start from this second.
Choose the zone
Pick the zone the instant should be read in. UTC comes first, the busier zones follow, and the full list is whatever your browser's own time-zone database knows.
Read the clock
The same moment appears beside your own zone and the shortlist with each offset, along with the instant as seconds, milliseconds and microseconds for whichever API asks.
What a timestamp is, and what this page does with it
Unix time counts seconds from 1970-01-01T00:00:00Z and deliberately ignores leap seconds, which is why the number is identical everywhere and a time zone is only ever a display choice. Ten digits cover 2001 to 2286, so a value copied out of a log or a URL is almost always seconds; a database column or a JavaScript date hands you thirteen digits, which are milliseconds of the same scale.
ISO 8601 writes the same thing on a calendar: 2026-09-12T14:30:00+03:00 is one instant expressed in Istanbul's wall clock, and Z means exactly +00:00. A string with no offset is ambiguous, so this page reads it as UTC rather than assuming your machine's zone. Offsets themselves come from your browser's tz database, which is why Europe/Istanbul stays at UTC+3 all year under the rule Turkey has kept since 2016, while America/New_York lands on UTC−4 or UTC−5 depending on the date.
Time conversion questions
Is my timestamp sent to a server?
No. The parsing and the zone maths run on the Intl API already installed in your browser, so the instant you look up is never transmitted and the page keeps working offline after it has loaded. Nothing is logged, because there is nothing to log it with.
Why does the same timestamp show a different hour for New York?
Because a zone's offset depends on the date: New York is UTC−5 in winter and UTC−4 in summer, and the browser applies whichever rule was in force at that instant. A conversion is therefore always between two instants, never between two zone names — change the timestamp and the offset can change with it.
Which of seconds, milliseconds and microseconds should I copy?
They are the same instant at three resolutions: a 10-digit Unix second count, a 13-digit millisecond one, and microseconds alongside both. APIs disagree about which they expect — Unix time is conventionally seconds, while browser and database timestamps are usually milliseconds — so take the one the tool or endpoint you are feeding asks for.
What happens if I paste a 12-digit number?
It is rejected instead of guessed, because only a 10-digit value is read as seconds and only a 13-digit one as milliseconds. Guessing would silently move the instant by decades, so a mistyped or truncated number is easier to catch as an error. An ISO 8601 date with an offset works just as well as a number and is unambiguous.