Convert between Unix timestamps and dates in any of 400+ time zones, in seconds, milliseconds, microseconds or nanoseconds
Initializing in your browser…
Convert times through the real IANA rules, flagging local times that happen twice and ones that never happen
Convert across 18 categories using exact defining factors, with the definition behind every number shown
Convert between ten colour notations including Lab and OKLCH, check WCAG contrast, and simulate colour vision deficiency
An incident log records 1700000000 and you need to line it up with a colleague in New York, on the phone, right now.
Unix timestamp
1700000000
The same instant, four ways
UTC 2023-11-14T22:13:20Z America/New_York 2023-11-14 17:13:20 -05:00 EST Europe/Berlin 2023-11-14 23:13:20 +01:00 CET Calendar Tuesday, day 318 of 365, ISO week 46 of 2023, Q4
A Unix timestamp is the same number everywhere; the zone only decides which clock face it corresponds to, which is exactly the thing that goes wrong on a call. Pick any of the 400+ zones and the wall clock, the offset and the abbreviation come from the IANA database, so a date in July gets EDT and one in November gets EST rather than a single hardcoded label. The unit is worked out from the number’s magnitude rather than from how many digits it has: the same 1700000000 as milliseconds would be January 1970, and the panel says which reading it took and what the others would have been. Going the other way, a wall clock that never happens or happens twice is named as such instead of getting one confident answer.
Convert a Unix timestamp into a date, or a date into a Unix timestamp, in any of the 400+ time zones the browser knows. Seconds, milliseconds, microseconds and nanoseconds are all read, and which unit a number is in is worked out from its magnitude rather than from how many digits it happens to have. A live counter at the top shows the current timestamp, and every result carries the wall clock, the UTC instant, both ISO 8601 forms, a relative description and the calendar fields: weekday, day of year, ISO week and quarter.
The unit question is the one most timestamp tools get wrong, and it is worth being precise about. Unix time is a count from 1 January 1970 UTC, but nothing in the number says whether it counts seconds, milliseconds, microseconds or nanoseconds. The usual approach is to count the characters: thirteen or more means milliseconds, fewer means seconds. That works for the range people normally paste and is silently wrong on either side of it. A thirteen digit number meant as seconds is the year 33658 and gets read as September 2001; a twelve digit number of milliseconds is September 2001 and gets read as the year 33658; a sixteen digit microsecond value, which is what a Chrome trace or a Postgres timestamp gives you, gets read as the year 55969. Here the units are three orders of magnitude apart, so magnitude answers the question properly: the reading that lands in a plausible range wins, the panel says which one it chose and what the other three would have meant, and setting the unit explicitly always overrides the guess rather than being overridden by a digit rule.
The zone work is done by the same resolver the timezone converter uses, which probes the offsets either side of a naive instant rather than round tripping a Date through a locale string. That matters in both directions. Reading a timestamp, it means the wall clock, the offset and the abbreviation come from the IANA database at that instant, so Moscow in July 2010 is +04:00 and in July 2016 is +03:00, Samoa on 20 December 2011 is -10:00 and a month later is +14:00, Kathmandu is +05:45, and New York is EST in January and EDT in July. Writing one, it means a local time that does not exist because the clocks went forward is named as such, with the instant the clock jumps to, and a local time that happens twice because the clocks went back offers both instants rather than picking one silently. Neither answer depends on the machine the page is open on: the same wall clock table comes back under four different machine time zones in the browser tests.
The boundaries are called out rather than left to be discovered. A value past 2147483647 gets a note that a signed 32-bit time_t wraps at 2038-01-19T03:14:07Z, and the negative end gets the same treatment at 1901-12-13T20:45:52Z. A negative timestamp is accepted and converted, with a note that plenty of software refuses them. A number too large for a date at all is refused with the reason rather than showing an "Invalid Date". Input that is not a whole number, such as 1e10, a decimal, or a comma-grouped figure, is refused by naming the character that is wrong, rather than being silently truncated by parseInt at the first character it cannot use.
The relative description is built from calendar arithmetic through Intl.RelativeTimeFormat rather than from thirty-day months. Twelve thirty-day months is 360 days, so a date thirteen months old lands in the wrong bucket under the usual approximation: 400 days ago is described here as thirteen months ago, not as a year. The calendar fields are computed the same way, including the ISO 8601 week number, which is not the same as the week of the year: 3 January 2010 is week 53 of 2009, and the tool says so.
There is also a text field for a date written out rather than as a number. It reads the ISO forms and RFC 2822, states in each case how it read the string (an explicit offset, no offset so read in the chosen zone, or a bare date read as UTC midnight), and refuses anything else rather than guessing. That refusal is deliberate: Date.parse is only specified for the ISO form, and every other shape is up to the engine, so a string that works in one browser can give a different instant or fail outright in another.
Paste 1704067200. It is read as seconds and resolves to 2024-01-01T00:00:00.000Z, with the wall clock in whatever zone is selected.
Paste 1704067200000000, the form a Chrome trace or a Postgres timestamp uses. It is read as microseconds and gives the same instant, where a digit-count rule would put it in the year 55969.
Click 2038 limit for 2147483647, which resolves to 2038-01-19T03:14:07Z with no warning, then One past it to see the warning appear.
Choose America/New_York, switch to Date to timestamp, and pick 8 March 2026 at 02:30. The panel says the clocks go forward through it and gives the instant they jump to.
A timestamp is the same number everywhere and the zone only decides the clock face. Pick the zone your colleague is in and read the wall clock they would have seen.
Paste the number and read the note: it says which unit it took and what the same value would mean in each of the other three, so a millisecond field mislabelled as seconds is obvious.
Enter the local date and time in the zone it applies to. If it falls in a gap or a repeat, the tool says so rather than returning one confident number.
The presets sit either side of the signed 32-bit limit, and any value past it carries a note naming the instant a 32-bit counter wraps.
From its magnitude, not its length. The units are three orders of magnitude apart, so only one reading usually lands in a plausible range. The panel says which it took and what the other three would have meant, and you can set the unit explicitly at any time.
It does not; the instant is the same number. The zone decides which clock face that instant corresponds to, and near midnight two zones can be on different calendar days for the same moment.
Going forward, an hour of local time never happens, and the tool says so and gives the instant the clock jumps to. Going back, an hour happens twice, and the tool gives both instants rather than picking one.
A signed 32-bit second counter runs out at 2147483647, which is 2038-01-19T03:14:07Z; the next second wraps to 1901. Anything past that value carries a note here. Sixty-four bit time is fine for another 292 billion years.
No, and they cannot be: Unix time is defined to ignore them, so every day is exactly 86,400 seconds and a leap second shares a timestamp with the second before it. Every implementation behaves this way.
Because Date.parse is only specified for the ISO form. Every other shape is implementation defined, so a string like "01/02/2024" means different things in different engines. The tool reads ISO 8601 and RFC 2822 and refuses the rest rather than guessing.
Conversions run on your device in JavaScript. The values you enter are never sent over the network.