How to Convert Between Time Zones Without Making Mistakes

A team stand-up gets scheduled for 9:00 AM in New York. Someone converts it for a colleague in Tokyo, gets the arithmetic backwards, and the invite lands at 9:00 AM Tokyo time instead of 11:00 PM — twelve hours and a wasted morning apart. This exact mistake happens constantly, and it is almost never a math problem. It is a method problem: most people try to convert time zones by intuition — "Tokyo is ahead, so I add something" — instead of by a fixed, repeatable rule.

This guide gives you that rule, a calculator to check your own numbers against it, and a rundown of the four specific mistakes that account for nearly every time-zone error people actually make. If you just need one conversion done for you right now, the time zone converter handles it directly; if you want to be able to do it correctly yourself, read on.

Every time zone is defined by an offset from UTC (Coordinated Universal Time) — a fixed reference that doesn't itself observe Daylight Saving. Converting a time from one zone to another is really just measuring the gap between two offsets and applying it to a clock reading. The zone's name or abbreviation — "Eastern Time," "CET," "JST" — is just a label; the offset is the only thing the math cares about. For a fuller explanation of what UTC is and how it relates to GMT, see the dedicated posts on what UTC actually is and how it differs from GMT.

An offset is written as a signed value, like +05:30 or −05:00, meaning "5 hours 30 minutes ahead of UTC" or "5 hours behind UTC." That sign is the entire trick to converting correctly. Get it backwards and the error isn't small — it's double the true gap, in the wrong direction, which is exactly the mistake covered in full further down.

Skip the geography entirely and use this instead:

• Step 1 — Get to UTC. Subtract the source zone's offset from the source local time.
• Step 2 — Get to the destination. Add the destination zone's offset to that UTC time.
• Step 3 — Check the date. If the total crossed midnight or dropped below 00:00, the calendar day moves too, not just the clock.

Put together as one line: destination time = source time + (destination offset − source offset). Because the sign of each offset is already built into that subtraction, you never have to reason about which direction is "ahead" — the numbers do it for you, in either direction, every time.

Before the worked example, run the arithmetic directly. Enter a time and pick the UTC offset you're starting from and the one you want, and both the result and any date shift update as you go.

New York runs on Eastern Time, UTC−05:00 in winter (standard time). Tokyo runs on Japan Standard Time, UTC+09:00 year-round — Japan does not observe Daylight Saving.

Now change one input: if that same call happened during New York's Daylight Saving period, its offset becomes UTC−04:00 instead of UTC−05:00. Run the same three steps and the Tokyo result shifts to 10:00 PM instead of 11:00 PM. Same New York clock time, same destination zone, an hour different — purely because the offset changed underneath it. It's a smaller shift than the direction mistake in the next section, but it's the one that's easiest to miss, because nothing about the setup looks wrong.

This is the single biggest source of time-zone errors, and it rarely feels like a mistake while you're making it. The usual failure is skipping straight to "there's a 14-hour difference" and then guessing which way to apply it, instead of writing down both offsets as signed numbers first.

Do it this way instead: write New York as −5 and Tokyo as +9, subtract source from destination once — 9 − (−5) = 14 — and add that single signed number to the local time. There is no separate "east means add, west means subtract" rule to remember, because the sign of each offset already encodes it. Reasoning about compass direction instead of the signed numbers is exactly how the sign gets flipped.

Plenty of zones don't hold one offset all year. In places that observe Daylight Saving, the UTC offset itself shifts by an hour for part of the year and shifts back later — the full mechanics of when and why are covered in the guide to Daylight Saving Time. The practical risk here is narrower: an offset you memorized once — "New York is UTC−5" — is only true for part of the year, and using it during the other part throws every conversion off by exactly an hour.

The two zones you're converting between don't necessarily change on the same date, either, so for a stretch each year one side may have already shifted while the other hasn't. The fix is simple: don't treat a zone's offset as a fixed fact. Check what it actually is for the specific date you're converting, especially near either zone's seasonal change.

When step 2 of the method pushes the total past midnight or below 00:00, the calendar date moves as well — not just the hour on the clock. A 9:00 PM call in Los Angeles, converted for a colleague in India, lands well into the following morning there. Update only the clock reading and skip the date, and you can send an invite for a day that's already passed or a day too early.

Whenever the offset difference is large enough to cross that boundary, write down which calendar day the result falls on explicitly, rather than trusting a bare clock reading on its own. The same logic applies, in an extreme form, when a conversion crosses the International Date Line — the clock difference can look ordinary while the date jumps by a full day.

Not every zone sits a whole number of hours from UTC. India runs on UTC+05:30, Iran on UTC+03:30, Afghanistan on UTC+04:30, and Nepal on UTC+05:45; the Chatham Islands sit at UTC+12:45. Round any of these to the nearest whole hour "to make the mental math simpler," and every conversion involving that zone is off by 15, 30, or 45 minutes — small on paper, large enough to miss a scheduled call or a departure. For the fuller list of offsets and the abbreviations attached to them, see the time zone abbreviations reference.

The fix mirrors the others: use the exact offset, including its minutes, rather than a rounded stand-in. If it's easier to track, convert the offset to minutes before doing the arithmetic and only convert back to hours and minutes at the end.

After computing a result, before you send it anywhere, ask one question: does the destination's clock time make rough sense for a normal day there? If a plainly daytime source hour converts to something like 3:00 AM at the destination for what should be an ordinary business hour, that's worth a second look — a sign error or a stale offset typically produces a wildly implausible time, not a subtly wrong one, so this catches most of them immediately.

It isn't foolproof — some meetings genuinely are scheduled at odd local hours on purpose — but pairing it with one more check closes most of the remaining gap: confirm that both offsets you used are the ones actually in effect on the date in question, not a pair memorized months ago.

Manual offset arithmetic is fine for a single, one-off conversion where you already know both current offsets and no Daylight Saving change sits between now and the date in question. It gets fragile fast beyond that: converting for a future date that crosses a DST boundary, coordinating more than two zones at once — which is really a different problem, covered in the guide to scheduling a meeting across multiple time zones — or anything where a mistake is genuinely costly, like a flight, a contract deadline, or a medication schedule.

In those cases, a proper converter applies the correct offset for the exact date automatically instead of asking you to remember it, and a meeting planner finds a workable slot across several people and zones without you running the same conversion over and over by hand.