24-hour or am/pm.

How this calculation works

The date and time you enter are treated as a wall-clock reading in the origin city. That reading is converted to a single point in time — an instant, independent of any zone — and then read back on the clock of the destination city.

The offset applied is the one in force on the date you chose, taken from the IANA time zone database in your browser. That matters because offsets are not constant: London is UTC in January and UTC+1 in July, and the two hemispheres change in opposite directions.

The hour that never happens

When clocks go forward, an hour is skipped. In the UK on 29 March 2026 the clock jumps straight from 00:59 to 02:00, so 01:30 does not exist that day. Entering it produces a clear warning and the instant the clocks moved to, rather than a silently wrong answer.

The hour that happens twice

When clocks go back, an hour repeats. In the UK on 25 October 2026 the clock reaches 02:00, returns to 01:00, and runs through the same hour again. A meeting at 01:30 that day is genuinely ambiguous, and the two possible instants are a full hour apart. Both are shown.

Cities and zones

Time zones cover regions rather than individual towns, so any city in the same zone gives the same answer. Cities are listed rather than raw zone identifiers because Europe/London is less obvious than London — but the underlying identifier is shown in the result so you can use it in a calendar invitation or a piece of software.

Worked example

14:00 on 30 July 2026 in London, converted to New York

  • London is on British Summer Time in July, UTC+1, so 14:00 is 13:00 UTC.
  • New York is on Eastern Daylight Time, UTC−4.
  • 13:00 UTC is therefore 09:00 in New York, the same calendar day.

In January the same clock time converts to 09:00 as well — but only by coincidence, because both cities have changed. In late March and early November, when the two countries switch on different dates, the gap is four hours instead of five.

Limitations

  • Historic dates use the rules recorded in the time zone database, which is incomplete before the 20th century.
  • Future dates assume current rules continue; governments change them at short notice.
  • Seconds are not handled, and leap seconds are ignored.

Frequently asked questions

Does this handle daylight saving?

Yes, in both directions. The offset used is the one in force on the date you enter, not today. Converting a meeting in October gives a different answer from the same clock time in July, which is exactly the trap that catches people booking ahead.

What happens if I pick a time that does not exist?

When clocks go forward an hour is skipped entirely — 01:30 on 29 March 2026 never happens in the UK. The calculator tells you, and gives the instant the clocks moved to, which is what calendar software does with an invalid start time.

What about a time that happens twice?

When clocks go back an hour repeats, so 01:30 on 25 October 2026 occurs twice in the UK — once on summer time and once on standard time. The calculator flags this and shows both readings, because the two are a full hour apart.

Where does the time zone data come from?

From the IANA time zone database built into your browser, which is the same source used by operating systems and most programming languages. Because it comes from your device rather than from this site, it stays current with rule changes as your browser updates.

Why is a city missing?

The list covers major cities rather than every settlement. Pick any city in the same time zone and country and the result will be identical — time zones cover regions, not individual towns.