Time Zone Converter

How to use the time zone converter

The page loads with a worked example: 09:00 on 15 September 2026 in New York, read in London. The answer, 14:00 the same day, appears without a submit step, and every row under it updates the moment you change a zone, the date or the time.

The date field is not decoration. Both London and New York move their clocks twice a year, on different dates, so the same 09:00 lands on 14:00 in September and January but 13:00 in the middle of March. Ask for a converted time without naming a date and the honest answer is a range.

Under the headline sit the rows that make the answer checkable. Each side shows its UTC offset and the zone name the database gives it that day, UTC-04:00 and Eastern Daylight Time against UTC+01:00 and British Summer Time, and the same moment appears once in UTC so two people can agree on it without agreeing on a city.

The last two rows are the ones ordinary converters leave out: the next clock change in each zone, written the way a public notice writes it. For New York on that date it reads Sun 1 Nov 2026, 02:00 goes back to 01:00, and for London Sun 25 Oct 2026, 02:00 goes back to 01:00. A zone holding one offset for the next 400 days says so instead.

Cities in the list sit anywhere from UTC-10:00 to UTC+12:00 in mid-June 2026, which is 23 distinct offsets on a single date. Four of them are not whole hours: Tehran at UTC+03:30, India at UTC+05:30, Nepal at UTC+05:45 and Adelaide at UTC+09:30.

The number of zones between two cities is also the input a jet lag estimate needs, and the difference row gives it directly whenever the gap is a whole number of hours, as it is between New York and London.

What if the hour you typed does not exist?

Converting a wall clock is not a subtraction, and once a year that shows. When clocks go forward an hour is deleted from the local day: 02:30 on 8 March 2026 in New York never happens, because 02:00 becomes 03:00 that morning. The tool flags the entry and reads it as 03:30.

The reverse case is worse, because it looks fine. When clocks go back an hour runs twice: 01:30 on 1 November 2026 in New York happens at 05:30 UTC while the city is still on EDT, and again an hour later at 06:30 UTC on EST. The tool reports both readings rather than picking one silently.

Europe gets the same two hours on its own dates. 01:30 on 29 March 2026 in London does not exist, because 01:00 becomes 02:00, and the entry is read as 02:30. 01:30 on 25 October 2026 happens twice: 00:30 UTC on BST, then 01:30 UTC on GMT.

South of the equator the mnemonic runs backwards. Sydney, Melbourne, Adelaide and Hobart put their clocks back on 5 April 2026, 03:00 going to 02:00, and forward again on 4 October. Auckland goes forward on 27 September 2026 and back on 5 April, so the two countries are briefly a week out of step.

Why this page holds no list of offsets

There is no offset table in this codebase, and there should not be. Every offset, zone name and clock-change date on the page is read at runtime from the device’s own copy of the IANA time zone database, through the same Intl formatting the browser already uses for dates.

That is not a detail. Of the 60 cities in the list, 31 hold a single offset for the whole year, and several arrived there recently: Brazil abolished daylight saving in 2019, Mexico in 2022 and Iran in 2022. Turkey moved to a permanent UTC+03:00 in 2016, and Russia stopped changing its clocks in 2014.

Those five are the argument for reading a live database rather than a table someone typed once. A page built on a stored offset for Mexico City would have been wrong from 2022 onwards, and nobody would have noticed until a meeting was missed.

The zone name is worth reading for the same reason. Intl gives New York Eastern Daylight Time in September and Eastern Standard Time in January, London British Summer Time and Greenwich Mean Time, and Kathmandu simply Nepal Time all year, because that zone has nothing to switch between.

The formula, worked line by line

Reading a clock is easy and writing one back is not. Intl only goes forward: hand it an instant and it will tell you the wall clock any zone was showing. This tool needs the inverse, because what you type is a wall clock, so it guesses and checks.

The offsets one day either side of the entered time bracket any transition close enough to matter. If they agree there is nothing to disambiguate. If they differ, each is a candidate: turn it into an instant, format that instant back in the zone, and keep it only if the zone really shows the clock that was asked for.

The survivors are the answer, and the count of them is the warning. One survivor is an ordinary hour. Zero means the hour was skipped, and the entry is carried past the gap by exactly its own width. Two means the hour ran twice, and both instants are reported. A subtraction can tell you none of that.

offset(zone, instant) = (the zone wall clock read as if it were UTC) − instant
candidates = offset one day before the entry, offset one day after
instant = (entered wall clock read as if it were UTC) − candidate offset
keep a candidate when formatting its instant in the zone gives back the exact clock entered
1 survivor = unique · 0 survivors = gap · 2 survivors = ambiguous
difference = target offset − source offset, in minutes
target wall clock = the surviving instant, formatted in the target zone

The next clock change is found the same honest way: step forward a day at a time until the offset differs, then bisect between those two days down to the minute. The scan stops after 400 days, and a zone that gets that far without moving is reported as having no change coming.

A curated list of 60 cities sits behind the two selects rather than the full IANA set, which runs to several hundred ids and makes a native select unusable. Only the id and the city label are stored. Nothing about how those zones behave lives in this repository at all.

Questions people ask