Your calendar converts between time zones correctly, and so does theirs. The mistakes that put two people on a call an hour apart happen before any event exists, in the messages two people write to each other. You assume where somebody is. A label means two different things. And for two weeks each spring, the gap between two cities moves.
- The conversion isn’t the risk. What you tell the calendar is, and it converts a wrong premise as faithfully as a right one.
- The cheapest fix here is naming a city instead of an abbreviation. “New York time” is true in July. “EST” names the winter.
- Write the same moment in both clocks. The error becomes theirs to spot, in a reply that was already coming.
- Twice a year the usual difference changes for a week or three. Countries move their clocks on dates they set separately, and a growing number now keep one offset all year.
The sum is not the part that fails
Once an event exists with a zone attached, the software is reliable. Google’s own help page says so plainly. “No matter where you create an event, everyone gets it in their own time zone.” Underneath, events are “converted into UTC, but you’ll always see them in your local time” (checked August 19, 2026). Outlook does the same thing. So does the phone in your pocket. People stopped counting on their fingers around the middle of the last decade.
All that machinery converts. It takes the zone you gave it and renders it in the zone your reader is in. Hand it a wrong zone and it gives you a wrong answer, computed flawlessly and shown with total confidence. A calendar knows the zone you typed. The client whose signature says London has been working from Lisbon since April, and that fact lives only in the correspondence.
So the problem sits somewhere unexpected. It lives in the prose, in the two or three messages you send before any event exists. Two people describe a moment in time to each other, in words. That’s the one part a person is still doing by hand, and it’s the part that goes wrong.
The cost runs far ahead of the size of the error. Sixty minutes is nothing. A meeting missed by sixty minutes lands much harder. One person sits in an empty call for ten minutes, then decides whether to write the awkward message. Whoever made the error apologizes, and to a client who missed the meeting it reads as being off the ball. That’s a large deposit of doubt for a mistake one word long.
Where the error actually gets in
Five things go wrong. The first four are human and the last one is technical. They’re worth naming separately, because the fixes differ.
The zone you assumed they were in. This is the commonest one by a wide margin, and it’s a research question rather than a scheduling one. A signature block gives you an office. The person can be somewhere else. A company registered in New York can have a finance director in Denver. Somebody you’ve emailed for two years may have moved, and updated their life rather than their footer. Arithmetic leaves this one alone. One clause in your sentence settles it.
The zone you assumed you were in. Rarer, and more embarrassing. You write the proposal from a hotel in another country, still thinking in the clock you left behind. Or your calendar account holds one zone as a setting while the laptop you’re typing on has picked up another. The event lands in whichever one the application believed.
The label you typed. Abbreviations are ambiguous, and half of them name a season rather than a place. This one has its own section below, because it’s the fix with the best return.
The day. A big enough gap moves the date, and “Thursday at 2” quietly becomes Friday. Two in the afternoon in London on a Thursday in February is one o’clock on Friday morning in Sydney. Anyone in Australia, New Zealand or East Asia has had this happen. It usually shows up as a meeting on the wrong day rather than at the wrong hour, which is harder to catch, because the time itself looks right.
The offset you memorized. An offset belongs to a place at a particular moment, and it changes for two separate reasons. The first is daylight saving, covered below. The second is that governments legislate, and they do it more often than anybody expects.
Every calendar, phone and operating system reads its rules from one shared source, the IANA time zone database. It’s amended whenever a country changes its mind. Three amendments have already shipped in 2026: release 2026a on March 1, 2026b on April 22 and 2026c on July 8 (checked August 19, 2026). Their contents are plain enough. British Columbia’s clock change on March 8, 2026, was its last, and the province moved to a permanent offset afterwards. Alberta did the same on June 18, 2026. Morocco is scheduled to stop changing its clocks on September 20, 2026, a month from now. Paraguay stopped after October 2024.
The database’s own maintainers put the warning best. “Users should not rely on particular UT offsets or abbreviations for timestamps.” The people who curate the numbers are telling you to look them up, and that’s worth taking at face value.
EST in July, and other zones that do not exist
Two separate things go wrong with abbreviations. Most people have met the first one.
The first is that one abbreviation can mean two places. The IANA maintainers’ notes are direct about it. “Application writers should note that these abbreviations are ambiguous in practice: e.g., CST means one thing in China and something else in North America, and IST can refer to time in India, Ireland or Israel.” They recommend a numeric offset instead. BST is British Summer Time to a reader in Britain and Bangladesh Standard Time to a reader in Dhaka, and those two are six hours apart.
The second one is quieter, and much more common in ordinary business email. An abbreviation like EST or PST names a place in a season. Eastern Standard Time is what the eastern United States observes in winter. From the second Sunday in March to the first Sunday in November, it observes Eastern Daylight Time, which is an hour different. So “3pm EST” written in July says something an hour away from what you meant. Most recipients correct it silently, which is the good outcome, and it’s why the habit survives. The ones who read it literally are usually the ones far enough away to have been relying on the label.
Britain has the same problem in reverse. GMT is what the UK observes in winter. From the last Sunday in March the UK is on British Summer Time, so “10am GMT” in August is out by an hour for anybody who takes it at its word.
The fix is free. Name the city.
“10:00 London time” and “09:00 New York time” read the same on every day of the year. They survive March untouched. People who have never given time zones a moment’s thought understand them on sight. If you want an abbreviation, the neutral forms beat the seasonal ones. ET, CT and PT hold true all year. That trick is local to those three, which is a reason to make city names the habit rather than memorizing which abbreviations are safe. For anybody genuinely far away, a numeric offset in brackets is worth the four characters: “09:00 New York time (UTC-4)”.
Two smaller ambiguities travel with the time. Close them in the same sentence.
Noon and midnight. NIST’s guidance is that “12 a.m. and 12 p.m. are ambiguous and should not be used”. The abbreviations mean before and after noon, and “since noon is neither before noon nor after noon, a designation of either a.m. or p.m. is incorrect” (checked August 19, 2026). They suggest the 24-hour clock instead. Across zones this matters more than it does at home. Your reader may be somewhere the 12-hour clock is unusual, and 12:00 read as 24:00 is a twelve hour error rather than a one hour one.
The date. 03/09 is the third of September to most of Europe and the ninth of March to the United States. Write the month in words, and put the day name next to it. Naming both gives you a free consistency check. If the day and the date disagree, one of them is wrong and somebody will notice.
Writing the time so the mistake announces itself
Here’s the whole method, and it’s one habit rather than a system. State the same moment twice, in two clocks.
“Thursday, September 3, 14:00 London time, which is 09:00 for you in New York. Half an hour.”
That second half is an error check. It’s performed by the one person in the exchange who always knows their own location. If you have the wrong idea of where they are, the words “09:00 for you in New York” read as plainly false to them, and they say so in the reply that was already coming. The mistake surfaces at the proposal stage, where one sentence fixes it, instead of on the morning, where it costs the meeting.
That’s the reason to write both. The rest is detail about what belongs in the line.
Both clocks, yours and theirs. If theirs is a guess, say so.
The city rather than the abbreviation, for the reasons above.
Your assumption, out loud. “I have assumed you are in New York, so tell me if not” is nine words, and it closes the largest single source of error in the subject. It also gives somebody who has moved a graceful way to mention it.
The date with the month in words, and the day name.
The length as well as the start. Across a big gap, a half hour at the edge of somebody’s day and a ninety minute session at that same edge are very different asks. One of the two is a reasonable thing to request.
The same habit works in the other direction, and this is the half people skip. When somebody offers you a time in their clock, restate it in yours before you agree. “Tuesday at 14:00 your time, so 19:00 here, which works.” That one restatement is the cheapest confirmation available anywhere in scheduling, and it catches the mismatch from the side of the person who got it right.
How many messages the arrangement takes is a separate question. That one turns on whether your first message carries an offer or a question, which is scheduling without the email chain. The two habits fit together comfortably: three real times, each written in both clocks.
What the invitation settles that the sentence cannot
Once a time is agreed, the authority moves from the prose to the calendar event, the way it should. The sentence was a check. The event is the record, and it stays right even if the other person is in a different country on the day.
Events travel in a format with three ways of writing a start time. It’s set out in RFC 5545, the specification calendars have exchanged events in since September 2009. Two of the three are safe. A time can carry an explicit zone reference, which is the normal case, or it can be written in UTC. The third carries a bare clock time, and the specification calls those values “floating”. A recipient “SHOULD interpret the value as being fixed to whatever time zone the ‘ATTENDEE’ is in at any given moment”. The spec then states the consequence plainly. “This means that two ‘Attendees’, in different time zones, receiving the same event definition as a floating time, may be participating in the event at different actual times.” Its own verdict is that “Floating time SHOULD only be used where that is the reasonable behavior.” A meeting between two people falls outside that.
Your own calendar knows your zone and attaches it, so floating times rarely come from you. They arrive from elsewhere: an event file generated by a web form, a booking confirmation from a smaller tool, an “add to calendar” link on a webinar page. The tell is easy to spot once you know it. A floating event shows the same clock time from whichever zone you look at it.
So there’s a ten second check worth making once the invitation goes out. It’s the last point where the error is still cheap. Open the event and read what it says in their clock. If that differs from the sentence you wrote in the message, one of the two is wrong, and you have days rather than minutes to find out which. What else belongs inside that event, so everybody has the joining link before nine fifty-eight, is writing a calendar invitation that arrives complete.
The weeks when the usual gap is not the usual gap
This is the part that catches careful people, because it defeats a habit rather than a calculation. You’ve known for years that New York is five hours behind London. For about four weeks a year the gap is four hours, and it changes quietly.
The dates differ because each side set its own. The United States fixed its own in the Energy Policy Act of 2005, effective from 2007. The statute reads “During the period commencing at 2 o’clock antemeridian on the second Sunday of March of each year and ending at 2 o’clock antemeridian on the first Sunday of November of each year”. The European Union’s Directive 2000/84/EC puts its change on the last Sunday in March and the last Sunday in October, at one in the morning GMT. Two rules, written separately, agreeing only by accident.
For a London and New York pair, that produced two windows in 2026.
- March 8 to March 29. New York sprang forward first, so for three weeks New York sat four hours behind London rather than five.
- October 25 to November 1. Britain fell back first, so for one week New York was again four hours behind rather than five.
The same shape repeats in 2027. The spring window runs from March 14 to March 28, and the fall one from October 31 to November 7. The gap narrows in both windows rather than widening, which is a small mercy and one worth checking rather than trusting.
The consequence for a standing meeting is specific, and it surprises people. A weekly call held at 14:00 London is 09:00 in New York for most of the year. During those windows it’s 10:00 there. Everybody involved did their job and the software worked. An event stored against a zone recurs at the same local clock time in that zone forever. So it sits still for whoever created it, and it shifts for everybody else. Somebody has to decide whose clock the meeting follows, the organizer’s or the attendee’s. Left alone, it follows the organizer’s, and the attendee finds out on the Monday.
The move is one sentence in the message before the changeover weekend. “Our usual 14:00 will be 10:00 rather than 09:00 for you for the next three weeks, until the clocks here change on the 29th.” Sent on the Friday, it’s free. Discovered on the Monday, it costs an hour of somebody’s morning.
Three more cases sit behind this one.
The southern hemisphere, where both ends move in opposite directions. Sydney is eleven hours ahead of London in the British winter and nine hours ahead in the British summer. In the two windows when only one of the pair has changed, it’s ten. That’s four changes a year and three different answers, which makes it a thing to look up every time.
The countries that never change, where the meeting moves anyway. This is the surprising one. India, most of Asia and Africa, the Gulf states and most of South America keep the same offset all year. A weekly call at 14:00 London is 19:30 in Mumbai in the British winter and 18:30 in the British summer. India held still. The meeting moved twice anyway, and the person absorbing it is the one whose clock stayed put. If you hold a standing meeting with somebody in a country that keeps one offset all year, they’re carrying the drift, and they may have absorbed it quietly.
The countries that used to change and stopped. The list moves. British Columbia stopped in March 2026, Alberta in June 2026, Paraguay in 2024, and Morocco is scheduled to stop on September 20, 2026. Europe has been on the verge of abolishing the change for years. The European Parliament adopted a position on March 26, 2019, supporting an end to seasonal clock changes. The European Commission’s own page still records that “The Council has not yet finalized its position”, which leaves Directive 2000/84/EC in force (checked August 19, 2026). So any offset you learned more than a couple of years ago deserves one look rather than trust.
Who ends up with the bad hour
Past a certain gap, every hour is inconvenient, and you’re choosing the least bad one. That choice is a social question rather than an arithmetical one.
The overlap is smaller than people assume. London and New York share about three hours of an ordinary working day. 14:00 to 17:00 in London is 09:00 to 12:00 in New York. London and Mumbai share about two and a half hours in the British winter and three and a half in the summer, so the window itself changes size at the changeover. London and Sydney share essentially none, which is why meetings between them land at the edge of somebody’s day by definition.
Three things follow.
Name the constraint rather than the preference. “My last workable slot for you is 17:00 here, which is 09:00 your time” shows somebody the shape of the problem. “Mornings are better for me” leaves that shape hidden, and invites a round of proposals that land outside it.
Decide who takes the awkward hour on purpose. By default it lands on whoever wants the meeting least, which is backwards. For a one-off, the person who asked for the meeting should offer to take the worse end. For anything standing, rotate it, and say in writing that you’re rotating it, so the other side knows the discomfort was noticed.
Consider whether the decision needs a live conversation at all. Across nine hours, an answer in writing that lands while the other person sleeps often beats the earliest call either of you can stand.
When somebody is simply picking a slot, a booking page takes this whole class of error off one side of the exchange, because it converts at the moment of looking. Calendly’s own documentation describes the behavior. Calendly “detects your invitee’s time zone automatically” and shows availability in their local time, with a dropdown if the detection is wrong (checked August 19, 2026). That’s the strongest argument there is for a link across a large gap. Choosing when a link fits and when it reads badly is a separate judgment: booking links that show real availability.
What a good habit here does not reach
Writing both clocks and naming cities closes most of this. Four things sit outside it, and knowing the edges saves you from over-engineering the rest.
A person who has moved and not said. A stale signature survives every convention. Asking catches it, which is why the stated assumption earns its nine words.
Travel arranged after the meeting was. You agree a time three weeks out and they fly somewhere in between. The event stays correct while their day moves, and the repair is somebody mentioning it. What happens next is when they ask to move a meeting, or, if you’re the one moving it, moving a meeting.
Four zones on one invitation. Every hour is bad for somebody, so the answer is a rotation or a recording. Pretending otherwise produces a meeting that three people attend properly and one attends at eleven at night.
Whether you’re free at all. A perfectly written time is still a guess when half your commitments live on a calendar your main one cannot see. That’s a separate and larger problem: reconciling two calendars.
Seeing somebody else’s clock without leaving your own
Point is a full email client, layered over the Gmail or Microsoft 365 account you run today. Point holds the thread and the calendar in one surface, rather than two windows you copy between. For this subject that matters in a narrow, useful way. The check you would otherwise run in your head, you run against the event itself, while you’re still writing the message.
Every event carries its time zone as a label, and the label is tappable. One tap opens a picker that takes a city, an abbreviation or a bare offset. New York, EDT and minus four all reach the same place, and the event redraws in that clock. Two o’clock Pacific reads as five o’clock Eastern, in front of you, while you’re deciding whether to offer it. The view is temporary by design. Dismiss it and the event reads in your own time again, with your defaults untouched. That’s the ten second check described above, done in the same window.
The rest of the arrangement runs on the thread. Say in plain words that a meeting needs setting up. Point checks your reconciled calendars, puts real times into the reply, and carries the correspondence from there. Point reads the answers in whatever words people used, however they phrase it. This works across time zones. Point also catches a request to move something when the request is buried in a paragraph about something else. When a time is settled, you approve it, and the event is written into your real calendar with everyone on it, as a real event rather than a note about one. Where a link is the better instrument, that same reconciled availability is what a shared page publishes, converted into the clock of whoever is looking.
Scheduling carries an autonomy dial that sits apart from the rest of Point, and review is the default there. In practice, the first few proposals and the first few invitations come past you before anyone else sees them. That’s how you satisfy yourself that the zones land where you expect. Raise the dial once a few threads have run in front of you. At the top setting, the back and forth is handled outright. Point logs each step in order, and undo walks back through that log, within the ordinary limit that an invitation already in a client’s calendar can be withdrawn rather than erased. The benefits page covers what changes across the rest of a mailbox.
Common questions
How do you schedule a meeting across time zones without getting it wrong?
Write the same moment twice, in both clocks, and name cities instead of abbreviations: “Thursday, September 3, 14:00 London time, which is 09:00 for you in New York.” Then say what you assumed. That second clock is an error check, performed by the one person who always knows their own location. It surfaces the mistake in the reply that was already coming, rather than on the morning of the meeting.
Should I write EST, Eastern Time, or New York time?
New York time. An abbreviation like EST names a season as well as a place. The eastern United States is on Eastern Daylight Time between March and November, so “3pm EST” in July is an hour away from what you meant if anyone reads it literally. One abbreviation can also mean two places. The IANA time zone maintainers note that CST means one thing in China and another in North America, and that IST can mean India, Ireland or Israel. A city name is correct every day of the year.
Why does my recurring meeting move by an hour twice a year?
Because a repeating event is stored against one time zone and recurs at the same local clock time there. It sits still for whoever created it, and it shifts for everybody else. A weekly 14:00 London call is 09:00 in New York most of the year, and 10:00 during the weeks when only one of the two countries has changed its clocks. Everything is working as designed. Somebody still has to decide whose clock the meeting follows, and by default it follows the organizer’s.
Which weeks do time zone differences change?
The ones where the two countries change on different dates. The United States moves on the second Sunday in March and the first Sunday in November. The European Union moves on the last Sunday in March and the last Sunday in October. In 2026 that gave two windows for a London and New York pair: March 8 to 29, and October 25 to November 1, during which New York was four hours behind rather than five. In 2027 the windows are March 14 to 28 and October 31 to November 7.
Whose time zone should the meeting be in?
Yours for the invitation, theirs for the sentence. The event is created against one zone, and the organizer’s is the sensible choice. That’s the calendar the meeting genuinely sits in, and it’s what everyone else’s calendar converts from. The message around it should lead with their clock, since that’s the number they’ll act on. Decide on purpose who takes the inconvenient hour when every hour is inconvenient.
Do I still need to name the time zone if I am sending a calendar invitation?
Yes, in the message, because the message is where a wrong assumption still gets corrected cheaply. The invitation is the record, and it’s reliable. A properly formed event carries its zone, and every recipient’s calendar renders it locally. But the invitation goes out only after a time has been agreed. If the agreement was built on a wrong idea of where somebody is, the event will be precisely and confidently an hour out.
The short version
Every calendar in the exchange converts correctly, and has for years. What goes wrong sits upstream, in the sentences two people write to each other before any event exists. A belief about where somebody is. An abbreviation that names a season, or two different continents. A date written in a format the other country reads backwards. An offset memorized at a moment when it happened to be true.
So the habit is short. Name cities rather than abbreviations. Write the moment in both clocks, and state the assumption you made about theirs. That turns your error into something the other person can see and mention for free. Put the month in words and the day name beside the date. Then let the event be the record, and spend ten seconds checking that it agrees with the sentence.
The part that survives all of that is the changeover weeks. The difference you’ve relied on for years is quietly wrong for somewhere between one and three weeks. The person absorbing the drift is often the one in a country that never changes its clocks at all. One sentence sent before the weekend covers it. A coaching practice running standing sessions with clients abroad will meet this four times a year, and should put the warning on the calendar rather than remember it. A consultancy arranging one-off calls has the opposite problem: every arrangement is a fresh chance to assume the wrong city. The rest of the trades this is built for fall somewhere between the two.