A time zone conversion is one moment, read on two clocks
There is only ever one instant — a call starts, a flight lands, a deadline closes. Every city simply reads that instant on its own clock, at its own distance from UTC. This converter takes a date and time in one city and restates it in another, using each zone's real offset on that exact date — which is the part fixed offset tables get wrong, because most zones move their clocks twice a year for daylight saving. Pick the same two cities in January and in July and you will often get two different gaps, and that difference is the truth about those clocks, not an error. The result also states the day shift plainly — same day, next day or previous day — because eastward conversions regularly land tomorrow, and a meeting booked for "Tuesday" in one city can be Wednesday in another.
The formula, with every term defined
The instant in UTC = the time you entered − the source zone's UTC offset on that dateConverted time = the instant in UTC + the target zone's UTC offset on that dateClock gap between the cities = target offset − source offset (in hours, for that date)
A zone's UTC offset is how far its clocks sit from Coordinated Universal Time on the date in question: New York reads UTC−5:00 in winter (Eastern Standard Time) and UTC−4:00 in summer (Eastern Daylight Time); London reads UTC+0:00 in winter and UTC+1:00 in summer (British Summer Time). Converting is therefore never "add five hours" as a permanent rule — it is two lookups, one per city, pinned to the date. Some offsets are not whole hours: India sits at UTC+5:30 all year and Nepal at UTC+5:45, which is why this page reports offsets to the minute rather than rounding them away.
Worked example: 9:00 AM in New York becomes 2:00 PM in London
The defaults above freeze a winter weekday so every figure can be checked. Thursday 15 January 2026, 09:00 in New York: New York is on standard time, UTC−5:00, so the instant is 09:00 + 5 = 14:00 UTC. London is on Greenwich Mean Time, UTC+0:00, so London reads exactly the UTC instant: 14:00 — 2:00 PM, the same day. The clock gap is 0 − (−5) = 5 hours, London ahead. Run the same instant around the world table under the result and the pattern of the planet appears: Los Angeles is still at 06:00, Dubai is at 18:00, Karachi at 19:00, Tokyo at 23:00 — and Sydney, at UTC+11:00 in its summer, has already crossed midnight to 01:00 on Friday 16 January. One phone call, seven clocks, two different calendar dates.
The same moment in seven cities — and what summer changes
| City | Thu 15 Jan 2026 | Wed 15 Jul 2026 |
|---|---|---|
| Los Angeles | 06:00 | 06:00 |
| New York (the entered time) | 09:00 | 09:00 |
| London | 14:00 | 14:00 |
| Dubai | 18:00 | 17:00 |
| Karachi | 19:00 | 18:00 |
| Tokyo | 23:00 | 22:00 |
| Sydney | 01:00 next day | 23:00 same day |
Read the July column carefully, because it breaks the rule most people carry in their heads. New York and London both spring forward, so their gap stays five hours and both still read 09:00 and 14:00. But Dubai, Karachi and Tokyo never move their clocks — so from their side, the New York moment arrives an hour earlier in July. Sydney moves the opposite way (it is in the southern hemisphere): its offset drops from UTC+11:00 to UTC+10:00, and the same 9:00 AM call that landed at 1:00 AM the next day in January lands at 23:00 the same day in July. There is even a short stretch each spring and autumn when the New York–London gap itself is temporarily four hours — on Sunday 15 March 2026, after the US has sprung forward but before the UK does, 09:00 in New York is 13:00 in London. Fixed "city difference" tables cannot show you any of this; a date-aware conversion can.
How to read your result, and the limits
The big figure is the target city's clock reading, with its weekday and date — check the day shift line before you write the meeting invite, because it is the single most common scheduling error across zones. Limits, stated plainly: offsets come from the international time zone database as your browser knows it, and governments occasionally change their rules (a zone abolishing daylight saving, for example) — for a legally binding deadline, confirm against the organiser's stated zone. Two clock times a year do not exist or exist twice in zones that spring forward and fall back: in the spring gap the converter resolves the instant consistently, but a local 2:30 AM on that one Sunday is a fiction in that city. For counting down to an event in whole days rather than clock time, use the countdown calculator; for durations inside a single working day, the hours calculator is the right tool.
Frequently asked questions
What time is 9:00 AM New York time in London?
On Thursday 15 January 2026 it is 2:00 PM in London — a five-hour gap, because New York is at UTC−5:00 and London at UTC+0:00 on that date. The gap is also five hours through most of the year, but it shrinks to four hours for a few weeks each spring and autumn when the two cities change their clocks on different Sundays.
Why does the gap between two cities change during the year?
Because each city moves its own clock on its own dates — or not at all. Dubai, Karachi and Tokyo never observe daylight saving, so their gap to New York narrows by an hour when New York springs forward. Sydney, in the southern hemisphere, moves in the opposite season entirely.
What does the day shift mean?
It tells you whether the converted moment falls on the same calendar date as the time you entered, the next day, or the previous day. Eastward conversions cross midnight often: 9:00 AM Thursday in New York is already 1:00 AM Friday in Sydney in January.
Are any time zones not a whole number of hours from UTC?
Yes. India is UTC+5:30 year-round, Nepal is UTC+5:45, and parts of Australia use half-hour offsets. This converter reports offsets to the minute — the offset shown beside each result is the real one for that date, not a rounded hour.
Does this converter use today's offset or the offset on my date?
The offset on your date — that is the whole point of entering a date and not just a time. A conversion for next July uses July's daylight-saving offsets, and a conversion for a date before a rule change uses the rules as they stood then, as recorded in the time zone database.
