How to convert time zones for a business call (and stop sending the wrong invite)
You have done this at least once. You confirm 3:00 PM with a client, they show up at 3:00 PM, and you show up eight hours later. Neither of you misread the email. You did the arithmetic in your head, against a rule set that changes four times a year and carries dozens of exceptions.
The fix is boring and takes six seconds: convert the time, then send the converted time instead of the raw one. The mental math fails for reasons that have nothing to do with being bad at arithmetic.
Open the Maplesheet Time Zone Converter →
The short version
- Open the Time Zone Converter.
- Enter the date and time you have and the city it belongs to.
- Pick the city you're converting to.
- Read the result, including the date, which may not be the same day.
- Share the link with everyone on the call so they see the same conversion you did.
That last step prevents most of the mistakes.
Why time zone math goes wrong
Daylight saving isn't synchronised
Countries that observe daylight saving don't switch on the same day.
In 2026, the United States moved its clocks forward on March 8. Europe and the UK didn't move theirs until March 29. For those three weeks, New York and London sat four hours apart instead of the usual five, and any recurring invite built on a hardcoded offset was wrong by an hour.
It happens again in autumn, in the other direction: Europe falls back on 25 October 2026, the US on 1 November 2026. Another week of shifted gaps.
None of this is going away in 2026. The US House passed the Sunshine Protection Act on 14 July 2026 by 308 votes to 117, but the bill still needs the Senate, and clocks are scheduled to change on 1 November as normal. The EU Parliament voted to abolish seasonal changes back in 2019 and member states have not agreed on which permanent time to adopt, so Europe keeps switching too, and you should plan for the clocks to change on both sides.
Plenty of places aren't on a whole-hour offset
The assumption that time zones differ by whole hours is wrong in a lot of commercially relevant places:
| Region | Offset |
|---|---|
| India, Sri Lanka | UTC+5:30 |
| Iran | UTC+3:30 |
| Nepal | UTC+5:45 |
| Newfoundland, Canada | UTC−3:30 |
| South Australia, Northern Territory | UTC+9:30 |
| Chatham Islands, NZ | UTC+12:45 |
If you have clients in Bengaluru, Mumbai, Colombo, or Adelaide, "add nine hours" lands you thirty minutes off. Adelaide carries a second trap: South Australia observes daylight saving and the Northern Territory, on the same standard offset, does not.
Time zone abbreviations are ambiguous
Three letters is not enough information, and several of the common ones collide:
- CST — US Central Standard Time (UTC−6), China Standard Time (UTC+8), or Cuba Standard Time
- IST — India Standard Time (UTC+5:30), Irish Standard Time (UTC+1), or Israel Standard Time (UTC+2)
- BST — British Summer Time (UTC+1) or Bangladesh Standard Time (UTC+6)
- EST vs EDT — New York is on EST in January and EDT in July. Writing "3 PM EST" in the middle of summer is an hour off
Naming a city removes the ambiguity. "3:00 PM Chicago" has one reading.
The date moves too
Most bookings that cross Asia–Pacific and the Americas land on a different calendar day. San Francisco 4:00 PM Tuesday is Tokyo 8:00 AM Wednesday. On those routes the failure is often a date error rather than an hour error: the right hour on the wrong day.
How to convert a date and time with Maplesheet
The Time Zone Converter runs in your browser, needs no account, and applies the daylight saving rules for the date you enter rather than the rules in force today.
Step 1 — Enter the source. Put in the date and time exactly as you have it, then select the city it belongs to. If a client wrote "Thursday 14:00," that's your source; their city is the source zone.
Step 2 — Pick the destination. Choose the city you want it converted into. If several people are joining from several places, convert to each one.
Step 3 — Read the whole result. Check the hour and the date. If the destination shows a different day, that's real, and it's the part you will skip when you're moving fast.
Step 4 — Look up the city if you're unsure. The tool has city pages A–Z if you need the offset for somewhere you don't work with often.
Because the conversion is tied to the date you enter, scheduling something for late March or late October gives you the correct offset for that specific day, including the weeks where the US and Europe are out of step.
Share the conversion instead of retyping it
Once you've converted the time, share the link rather than pasting the number into an email and hoping.
A re-typed time is a chance to introduce an error, and a "sorry, is that your 3 or my 3?" reply costs you a day of round trip. Send the link and the other side opens it, sees the same result you did, in the same context, with the date attached.
It's most useful when:
- The invite has more than two zones on it. A list of five converted times is a list your attendees will scan too fast to find their own line.
- You're still negotiating the slot. Send the link with two candidate times and let people answer against it.
- The meeting is near a clock change. In late March, late October or early November, send the link and let the tool settle it.
- You're handing off to someone else's calendar. An assistant booking on your behalf shouldn't have to reconstruct your maths.
Drop the link into the calendar invite description, the Slack thread, or the confirmation email, and the whose-3-o'clock thread never starts.
Typical overlap windows for common pairs
These are the workable slots during northern-hemisphere summer. They shift by an hour at each clock change, so confirm the specific date before you send anything.
| Route | Gap | Comfortable window |
|---|---|---|
| New York ↔ London | 5h | 9–11 AM New York / 2–4 PM London |
| San Francisco ↔ London | 8h | 8–10 AM San Francisco / 4–6 PM London |
| New York ↔ Berlin | 6h | 8–10 AM New York / 2–4 PM Berlin |
| London ↔ Singapore | 7h | 9–11 AM London / 4–6 PM Singapore |
| New York ↔ Bengaluru | 9h30 | 8–10 AM New York / 5:30–7:30 PM Bengaluru |
| San Francisco ↔ Tokyo | 16h | 3–5 PM San Francisco / 7–9 AM Tokyo, next day |
| London ↔ Sydney | 9h | 8–9 AM London / 5–6 PM Sydney |
Watch Sydney. The gap from London swings between 9, 10 and 11 hours across the year because the two hemispheres change clocks in opposite directions, and the usable window runs about an hour wide at its best.
Five mistakes worth avoiding
- Hardcoding an offset into a recurring meeting. "Always 9 AM New York = 2 PM London" is true for about 48 weeks a year.
- Writing EST year-round. Name the city, or give UTC.
- Treating London as GMT in July. London runs on BST, UTC+1, for seven months of the year.
- Confirming the hour and forgetting the day. Especially on any route crossing the Pacific.
- Assuming the other side observes daylight saving at all. Iceland, Turkey, Russia and Belarus don't. Neither do Hawaii or most of Arizona, nor most of Asia and Africa.
Write the confirmation so it holds up
A confirmation that can't be misread looks like this:
Thursday 15 October, 9:00 AM New York / 2:00 PM London (13:00 UTC) Converted here: [link]
City names, both local times, UTC as the tiebreaker, and a link that proves it, in two lines.
FAQ
What's the best way to convert a time zone for a meeting? Enter the date, the time and the source city into a converter, read off the destination time and date, then share the result rather than retyping it. Doing it by hand fails around clock changes and in half-hour-offset countries.
Is EST the same as EDT? No. EST is UTC−5 and applies in winter; EDT is UTC−4 and applies during daylight saving. Writing "EST" in July is an hour off. Naming the city instead avoids the problem.
Should I write UTC or GMT? Use UTC. GMT is often used loosely to mean "London time," but London is on UTC+1 for most of the year, so GMT is a misleading label in summer.
How do I schedule a call between the US and India? India is UTC+5:30 and doesn't observe daylight saving, so the gap from New York moves between 9.5 and 10.5 hours depending on the US clock. Early morning US / early evening India is the realistic overlap. Convert the exact date rather than reusing a remembered offset.
Does the converter handle daylight saving automatically? Yes. It applies the rules for the date you enter rather than today's rules, so a meeting booked for late October gets the offset in effect on that day.
Can I share a converted time with other people? Yes. Share the conversion link and everyone sees the same result, which removes the back-and-forth about whose time zone a number was quoted in.