How to convert time zones for a business call (and stop sending the wrong invite)
Everyone who works across borders has done it 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. Nobody was wrong, exactly. You were just doing arithmetic in your head with a rule set that changes four times a year and has thirty-eight exceptions.
The fix is boring and takes six seconds: convert the time properly, then send the converted time instead of the raw one. Here's how to do it, and why the mental math fails more often than people expect.
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 is the one that actually prevents mistakes. Keep reading for why.
Why time zone math goes wrong
Daylight saving isn't synchronised
This is the big one. 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 were four hours apart instead of the usual five — and every recurring invite created with a hardcoded offset was quietly wrong.
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.
If you're wondering whether this is all about to go away: as of July 2026, no. The US House passed a bill to make daylight saving permanent in mid-July, but it 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 never agreed on which permanent time to adopt, so Europe keeps switching too. Plan for the clocks to change.
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 |
| Parts of South Australia and the Northern Territory | UTC+9:30 |
| Chatham Islands, NZ | UTC+12:45 |
If you have clients in Bengaluru, Mumbai, Colombo, or Adelaide, "add nine hours" is never going to land on the right minute.
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 technically an hour off
Naming a city removes the ambiguity entirely. "3:00 PM Chicago" cannot be misread. "3:00 PM CST" can.
The date moves, not just the hour
Anything crossing Asia–Pacific and the Americas usually lands on a different calendar day. San Francisco 4:00 PM Tuesday is Tokyo 8:00 AM Wednesday. Half of all "wrong meeting" incidents on those routes are date errors, not hour errors — the time was right and the day was not.
How to convert a date and time with Maplesheet
The Time Zone Converter runs in your browser, needs no account, and handles the daylight saving rules for the specific date you enter — not just today's rules.
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 exactly the thing that gets missed.
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 temporarily out of step.
Share the conversion instead of retyping it
Once you've converted the time, don't paste the number into an email and hope. Share the link.
Every re-typed time is a chance to introduce an error, and every "sorry, is that your 3 or my 3?" reply is a round trip that delays the booking by a day. A shared conversion link gives everyone the same source of truth: they open it and see 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. Nobody wants to read a list of five converted times and figure out which line is theirs.
- You're negotiating a slot, not confirming one. Send the link with two or three candidate times and let people answer against it.
- The meeting is near a clock change. Late March, late October, early November — send the link and let the tool be right rather than arguing about 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. It costs nothing and removes the entire class of problem.
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 |
Sydney is the one to watch. 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 is only about an hour wide even 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 roughly 46 weeks a year.
- Writing EST year-round. Use the city name, or use UTC, or use both.
- Treating London as GMT in July. London is 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 invite so nobody has to guess
A confirmation that can't be misread looks roughly 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. Three lines, zero ambiguity.
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, not just today's, so a meeting booked for late October gets the offset that will actually be in effect then.
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.
Ready to book the call? Convert the time first →