Convert times through the real IANA rules, flagging local times that happen twice and ones that never happen
Initializing in your browser…
Convert between Unix timestamps and dates in any of 400+ time zones, in seconds, milliseconds, microseconds or nanoseconds
Convert images between PNG, JPG, WebP, AVIF, BMP formats. Features quality control, transparency support, and batch conversion for efficient workflow.
Convert between MP3, WAV, OGG, AAC, M4A and FLAC with a bitrate, sample rate, channel count and bit depth that all reach the encoder, and a panel that reports what was actually written.
A meeting is booked for 01:30 on 1 November 2026 in New York, the night the clocks go back. Which 01:30?
Source time
2026-11-01 01:30, America/New_York
Result
That local time happens twice. First pass (EDT, -04:00) = 2026-11-01T05:30:00Z Second pass (EST, -05:00) = 2026-11-01T06:30:00Z Pick one. Second pass in UTC: 6:30 AM, Sun 1 Nov 2026
The wall clock is resolved into a real instant before anything else happens, by probing the offsets in force either side of it. A local time inside a fall-back overlap matches two instants and both are offered; a local time inside a spring-forward gap matches none and the tool says so rather than returning a confident answer. Rules come from the IANA database the browser ships, so historical entries work too: Moscow in July 2010 converts at UTC+4 and July 2015 at UTC+3.
A wall clock is not an instant, and that is where time zone conversion goes wrong. Twice a year, on the night a region moves its clocks, one local time has no instant at all and another has two. Ask most converters for 2:30 AM on 8 March 2026 in New York and they will hand back a confident answer, even though that minute never happens: the clock goes straight from 1:59:59 to 3:00:00. Ask for 1:30 AM on 1 November and they will pick one of the two 1:30s without telling you there was a choice. This tool reports both cases, names which instants exist, and lets you pick when there are two. All four modes work through Intl.DateTimeFormat, so the rules come from the IANA database your browser already ships, historical entries included. Moscow was UTC+4 in July 2010 and UTC+3 in July 2015, and converting those two dates gives two different answers rather than one rule applied to both. Samoa skipped 30 December 2011 entirely when it crossed the date line, and dates either side of that jump land correctly. Every zone the browser knows is available, which is currently more than 400, not a curated shortlist, and half-hour and 45-minute offsets such as India and Nepal are handled like any other.
The Time Converter takes a wall clock, a source zone and a target zone, and resolves the wall clock into a real instant before doing anything else. Resolution probes the offsets in force a day either side of the naive time, which spans any transition the wall clock could be sitting on: a local time inside a spring-forward gap matches none of them and is reported as one that never happens, and a local time inside a fall-back overlap matches two, which are offered as First pass and Second pass with their respective abbreviations. Once the instant is fixed, the result shows the local time on both sides with the abbreviation and the UTC offset that applied at that instant, the UTC instant in ISO 8601, both zones in ISO 8601 with their own offsets, the difference between the zones, whether the target has crossed into the next or previous day, and when the target zone next changes offset.
Abbreviations come from the database rather than a fixed table, so London reads GMT in January and BST in July, Sydney reads AEDT in January and AEST in July, and New York reads EST or EDT rather than a generic label. No single locale in CLDR carries every letter code, so three are tried in turn and the first real abbreviation wins; zones that genuinely have no letter code, such as India, fall back to their numeric offset rather than being given an invented one.
World Clock ticks once a second and shows, for each zone, the current time, the abbreviation and offset in force right now, the full zone name, whether daylight saving is currently in effect, and a day or night indicator. The daylight-saving flag is worked out by comparing the current offset with the smallest offset the zone uses that year, so it is right in the southern hemisphere too: Sydney reads as on daylight saving in January, not July. Meeting Scheduler builds a 24-row grid whose hour column is anchored to a zone you choose and which is named on screen; a cell is green when every participant is inside working hours, yellow when only that participant is, and dimmed otherwise, with a marker when a participant has crossed into the next or previous day. Unix Epoch converts a timestamp in seconds or milliseconds and renders it in the zone you select as well as in UTC, your browser zone, ISO 8601 with and without an offset, and as a relative phrase.
In Meeting Scheduler, keep the default New York, London and Tokyo participants, set the hour column to whichever city is running the meeting, set Work Hours to 9 AM and 5 PM, and read down the grid for the green rows where all three are inside working hours.
Set the date to 1 November 2026, the time to 01:30 and the source zone to New York. The tool reports that the local time happens twice and offers both instants, an hour apart, one EDT and one EST.
In Unix Epoch mode, paste 1700000000 with the unit set to Seconds to see the instant in your chosen zone, your browser zone, UTC, and ISO 8601, each individually copyable.
Find overlapping work hours between teams in different zones, with the hour column anchored to whichever office is running the meeting.
Announce an online event with the correct local time for attendees worldwide, and catch it early if the date you picked falls on a transition night.
Convert timestamps in UTC-based logs to a local time, or go the other way and get the ISO 8601 instant to paste into a query.
Work out what a 2010 Moscow timestamp or a 2011 Samoa date actually meant, using the rules that were in force then rather than the ones in force now.
Yes, including the two cases most converters get wrong. On the night clocks go forward, one hour of local time does not exist, and the tool says so instead of inventing an answer. On the night they go back, one hour happens twice, and the tool offers both instants rather than picking one silently.
You get a red warning naming the gap and the offsets either side of it, and the result shows the instant the clock jumps to. That is what calendar systems generally do with an appointment booked inside the gap.
No. The wall clock you type is resolved in the source zone you chose, not in your browser zone. The tool names your browser zone under the result so you can see it is not being used for the conversion.
Yes, because it reads the IANA database your browser carries rather than a fixed offset per city. Moscow was UTC+4 in July 2010 and UTC+3 in July 2015; converting those two dates gives two different answers.
Zones are listed by region and city (America/New_York). Smaller places share a zone entry with the nearest city in the same zone. Every zone the browser knows is offered, which is currently over 400.
Unix time and JavaScript dates do not represent leap seconds; a leap second shares its timestamp with the second before it. Times on either side of one convert normally, which is what every system built on Unix time does.
Conversions run on your device in JavaScript. The values you enter are never sent over the network.