To calculate a time zone difference, convert through UTC in two steps: subtract the source zone's UTC offset from the local time to get UTC, then add the target zone's offset. Use each zone's offset on that specific date, because daylight saving changes them. Example: 09:00 in London (UTC+1) is 08:00 UTC, which is 04:00 in New York (UTC−4).
That is the whole method. Everything below is about the four things that make it go wrong in practice: offsets that aren't whole hours, dates that roll over, daylight saving windows where two regions disagree, and time zone abbreviations that mean two different things.
What is a UTC offset, and why convert through it?
Every civil time zone on Earth is defined as a displacement from UTC (Coordinated Universal Time), written as a signed hours-and-minutes value: UTC−5, UTC+2, UTC+5:30. UTC itself never shifts — it has no daylight saving and no seasons.
That makes UTC a pivot. Instead of memorising the relationship between every pair of the world's zones, you learn one offset per zone and route every conversion through the middle:
local time − source offset = UTC
UTC + target offset = target local time
Note the sign carefully, because this is where most manual conversions break. Subtracting a negative offset adds. New York in summer is UTC−4, so 15:00 − (−4) = 19:00 UTC. Read it as "New York is 4 hours behind UTC, so UTC is 4 hours ahead of New York."
The same "convert through a neutral reference" pattern shows up everywhere in everyday conversions — it is exactly how you go from one unit system to another via a base unit, and how number bases convert through decimal.
How do I convert a time between two zones step by step?
Worked example — 2:30 PM in Chicago during summer, in Mumbai:
- Chicago in summer is on CDT, UTC−5. Local 14:30 − (−5) = 19:30 UTC.
- India is UTC+5:30 all year. 19:30 + 5:30 = 25:00 → subtract 24 h and roll the date forward: 00:30 the next day.
So a 2:30 PM Tuesday call in Chicago is 12:30 AM Wednesday in Mumbai. The difference is 10 hours 30 minutes — and it is not a whole number of hours, which is the first thing a mental shortcut gets wrong.
A second worked example, this time crossing the date line — 9:00 PM Tuesday in Los Angeles, in Tokyo:
- Los Angeles in summer is PDT, UTC−7. 21:00 − (−7) = 28:00 → 04:00 UTC Wednesday.
- Japan is UTC+9 year-round. 04:00 + 9 = 13:00 Wednesday in Tokyo.
Tuesday evening in California is Wednesday lunchtime in Japan: 16 hours ahead.
What's a quick reference table for common zones?
The table below converts a single instant — 09:00 in London during British Summer Time (UTC+1), which is 08:00 UTC — into a set of common business zones. Offsets shown are those in effect in July; zones marked with an asterisk change with daylight saving at other times of year.
| City | UTC offset (July) | Local time | Difference vs London |
|---|---|---|---|
| Los Angeles | UTC−7* | 01:00 | −8 h |
| New York | UTC−4* | 04:00 | −5 h |
| São Paulo | UTC−3 | 05:00 | −4 h |
| London | UTC+1* | 09:00 | — |
| Berlin | UTC+2* | 10:00 | +1 h |
| Johannesburg | UTC+2 | 10:00 | +1 h |
| Dubai | UTC+4 | 12:00 | +3 h |
| Mumbai | UTC+5:30 | 13:30 | +4 h 30 min |
| Kathmandu | UTC+5:45 | 13:45 | +4 h 45 min |
| Singapore | UTC+8 | 16:00 | +7 h |
| Tokyo | UTC+9 | 17:00 | +8 h |
| Sydney | UTC+10* | 18:00 | +9 h |
| Auckland | UTC+12* | 20:00 | +11 h |
Check any row yourself: take 08:00 UTC and add the offset. Mumbai is 08:00 + 5:30 = 13:30. Los Angeles is 08:00 + (−7) = 01:00. Auckland is 08:00 + 12 = 20:00.
Sydney and Auckland carry an asterisk for the opposite reason to the northern cities: they are in the southern hemisphere, so their daylight saving runs roughly October to April. In January, Sydney is UTC+11 and Auckland UTC+13 — each an hour further ahead than the table shows.
Why is my time zone calculation an hour off?
Nine times out of ten, daylight saving. Four specific failure modes:
1. You used a memorised difference instead of the offsets. London to New York is "usually 5 hours", so people subtract 5 always. But the US springs forward on the second Sunday of March while the UK and EU change on the last Sunday of March. In that gap, New York is UTC−4 while London is still UTC+0 — a 4-hour difference. The same mismatch reappears in autumn, when the EU falls back on the last Sunday of October and the US on the first Sunday of November.
2. You assumed both regions have daylight saving at all. Most of Asia, Africa and South America don't. Japan, India, China, the UAE, South Africa and Brazil all hold one offset year-round. If Brazil doesn't move but the UK does, the São Paulo–London gap changes twice a year without São Paulo doing anything.
3. You assumed offsets are whole hours. India is UTC+5:30, Nepal UTC+5:45, parts of Australia UTC+9:30, the Chatham Islands UTC+12:45. Any calculation done only in whole hours is silently wrong across a large slice of the world's population.
4. You trusted an abbreviation. "CST" is Central Standard Time (UTC−6), China Standard Time (UTC+8), and Cuba Standard Time (UTC−5). "IST" is Indian, Irish or Israel Standard Time depending on the sender. When it matters, write a city name or an explicit offset, never a three-letter code.
How do I handle dates that roll over?
Arithmetic beyond 24:00 or below 00:00 changes the calendar day, and forgetting that turns a correct hour into the wrong meeting.
- Result is 24:00 or more: subtract 24 hours and move the date forward one day. 19:30 UTC + 5:30 = 25:00 → 00:30 the next day.
- Result is negative: add 24 hours and move the date back one day. 02:00 UTC + (−7) = −05:00 → 19:00 the previous day.
This is also why "same time next week" is not always the same offset apart: if a daylight saving switch falls between the two dates, the gap moves. Recurring international meetings drift by an hour twice a year for exactly this reason — the meeting is anchored to one participant's local clock, and everyone else's relationship to it changes.
How do I write a time so nobody miscalculates it?
Use ISO 8601 with an explicit offset when the exact instant matters:
2026-07-14T14:30:00-05:00. That string pins one moment with no interpretation
required — the offset is right there, so no reader has to guess whether daylight
saving was in effect.
For invitations to humans, name the city and the offset together: "2:30 PM Chicago time (UTC−5)". City plus offset survives forwarding, screenshots, and recipients in zones you never considered. For anything machine-facing, a Unix timestamp sidesteps zones entirely — it is a single count of seconds since 1970-01-01 00:00:00 UTC, identical everywhere on Earth, and only its display varies.
FAQ
What is the formula for converting between time zones?
target local time = local time − source UTC offset + target UTC offset, with
each offset taken for that specific calendar date. Roll the date forward if the
result reaches 24:00 or more, and back if it goes negative.
How do I calculate the difference between two time zones directly?
Subtract the source offset from the target offset: target minus source. Tokyo (UTC+9) minus New York in summer (UTC−4) = 9 − (−4) = 13, so Tokyo is 13 hours ahead. Recheck whenever either zone's daylight saving status changes.
Do all time zones differ by whole hours?
No. India is UTC+5:30, Nepal UTC+5:45, parts of Australia UTC+9:30, and the Chatham Islands UTC+12:45. India alone puts well over a billion people on a half-hour offset, so always calculate with hours and minutes.
Why does the time difference between two cities change during the year?
Because daylight saving offsets change, and regions change on different dates — or not at all. The US switches in March and November, the EU in March and October, the southern hemisphere in the opposite months, and much of Asia and Africa never. Always use the offset in effect on your target date.
Does UTC ever change with daylight saving?
No. UTC is a fixed reference with no seasonal adjustment, which is exactly why it works as the pivot for every conversion. GMT is often used loosely as a synonym, but the UK's civil time moves to UTC+1 in summer while UTC does not.
Need a meeting time moved across three zones right now? Medley Web is building a free hub of instant, in-browser tools — timezone conversion, epoch timestamps, and duration calculators among them — one input in, many formats out. Convert times across zones free at medley-web.com.
