Every calendar involved in a meeting already knows how to convert between zones, and it converts correctly. The mistakes that put two people on a call an hour apart are made before any of that: in a belief about where somebody is, in a label that means two different things, and in a fortnight each spring when the gap between two cities is not the gap everybody memorised.
- The conversion is not the risk. What you told the calendar is the risk, and it converts a wrong premise as faithfully as a right one.
- The cheapest fix in the whole subject is naming a city instead of an abbreviation. “New York time” is true in July. “EST” is not.
- Write the same moment in both clocks and the error becomes somebody else’s to spot, in a reply that was already coming.
- Twice a year the usual difference is wrong for a week or three, because countries change their clocks on dates nobody coordinated and a growing number no longer change them at all.
The sum is not the part that fails
Once an event exists with a zone attached to it, the software is reliable. Google’s own help page says it plainly: “No matter where you create an event, everyone gets it in their own time zone”, and describes the mechanism underneath, which is that events are “converted into UTC, but you’ll always see them in your local time” (checked 19 August 2026). Outlook does the same thing. So does the phone in your pocket. Nobody has needed to count on their fingers since about the middle of the last decade.
What none of that machinery can do is check the premise it was handed. It converts from the zone you gave it to the zone the reader is in, and if the first of those is wrong the answer is wrong, computed flawlessly and displayed with total confidence. A calendar cannot know that the client whose signature says London has been working from Lisbon since April.
Which puts the whole problem in an unexpected place. It lives in the prose, in the two or three messages sent before any event exists, where two people are describing a moment in time to each other in words. That is the only part of this a machine is not doing, and it is therefore the only part that goes wrong.
The cost of getting it wrong is also out of proportion to the size of the error. Sixty minutes is nothing, but a meeting missed by sixty minutes is not a small meeting problem. One person sits in an empty call for ten minutes and then has to decide whether to write the awkward message. Whoever made the error apologises for something that reads, to a client who was not there, as not being on top of things. That is a large deposit of doubt for a mistake that was one word long.
Where the error actually gets in
Five things go wrong, and only the last of them is remotely technical. They are worth naming separately because the fixes are different.
The zone you assumed they were in. This is the commonest by a distance, and it is not a scheduling failure at all. It is a research failure. A signature block gives you an office, not a person. A company registered in New York can have a finance director in Denver. Somebody you have emailed for two years may have moved, and the thing they changed was their life rather than their footer. Nothing in the arithmetic protects you from this, and one clause in a sentence does.
The zone you assumed you were in. Less common 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 are typing on has picked up another, and the event lands in whichever of those the application decided to believe.
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 is the fix with the best return.
The day. A large 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 to them, usually as a meeting that appeared on the wrong day rather than at the wrong hour, which is harder to spot because the time looks fine.
The offset you memorised. An offset is not a property of a place. It is a property of a place at a particular moment, and it changes for two separate reasons. The first is daylight saving, dealt with 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, which is amended whenever a country changes its mind. Three amendments have already shipped in 2026: release 2026a on 1 March, 2026b on 22 April and 2026c on 8 July (checked 19 August 2026). What they contain is not obscure. British Columbia’s clock change on 8 March 2026 was its last, and the province moved to a permanent offset afterwards. Alberta did the same on 18 June 2026. Morocco is scheduled to stop changing its clocks on 20 September 2026, a month from now. Paraguay stopped after October 2024.
The database’s own maintainers put the warning better than anybody else has: “Users should not rely on particular UT offsets or abbreviations for timestamps.” If the people who curate the numbers say not to memorise them, that is worth taking at face value.
EST in July, and other zones that do not exist
Two separate things are wrong with abbreviations, and most people have only noticed the first.
The first is that they are not unique. 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.” Their recommendation is to use a numeric offset instead of an abbreviation. BST is British Summer Time to a reader in Britain and Bangladesh Standard Time to a reader in Dhaka, and the two are six hours apart.
The second is subtler and much more common in ordinary business email. An abbreviation like EST or PST does not name a place. It 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 is a sentence that cannot be read literally without being wrong. Most recipients will silently correct it to what you meant, which is the good outcome and also the reason the habit survives. Some will not, and the ones who do not are usually the ones far enough away that they were relying on the label.
Britain has exactly the same problem in reverse. GMT is what the UK observes in winter. From the last Sunday in March it is on British Summer Time, and a message saying “10am GMT” in August is out by an hour if anybody takes it at its word.
The fix costs nothing. Name the city.
“10:00 London time” and “09:00 New York time” are unambiguous on every day of the year, need no revision in March, and are understood by people who have never given time zones a moment’s thought. If you want an abbreviation, the neutral forms are better than the seasonal ones: ET, CT and PT do not claim a season, and the same trick works nowhere else, which is a reason to prefer city names as a habit rather than remembering 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 and are worth closing 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”, for the plain reason that 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 19 August 2026). Their suggested alternative is the 24-hour clock. Across zones this matters more than it does at home, because 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 is 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 is the whole method, and it is one habit rather than a system. State the same moment twice, in two clocks.
“Thursday 3 September, 14:00 London time, which is 09:00 for you in New York. Half an hour.”
The second half of that sentence is not politeness and it is not there to save the reader arithmetic they were not going to do anyway. It is an error check, performed by the one person in the exchange who cannot get their own location wrong. If you have the wrong idea of where they are, the words “09:00 for you in New York” are visibly false to them, and they will say so in the reply that was already coming. The mistake surfaces at the proposal stage, where correcting it costs one sentence, rather than on the morning, where it costs the meeting.
That is the reason to write both. Everything else is the detail of what belongs in the line.
Both clocks, yours and theirs. If you genuinely do not know theirs, that is the thing to say.
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, not just the start. Across a big gap, a half hour that starts at the edge of somebody’s day and a ninety minute session that starts at the same edge are very different propositions, and only one of them is a reasonable thing to ask for.
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 single restatement is the cheapest confirmation available anywhere in scheduling, and it catches the mismatch on the side of the person who was not making the mistake.
None of this changes how many messages the arrangement takes. What decides that is whether your first message contains an offer or a question, which is scheduling without the email chain, and the two habits sit 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, and it should. The sentence was a check. The event is the record, and it is the thing that will still be right if the other person is in a different country on the day.
The format events travel in has three ways of writing a start time, set out in RFC 5545, the specification calendars have exchanged events in since September 2009. Two of them are safe. A time can carry an explicit zone reference, which is the normal case, or it can be written in UTC. The third has no zone at all, and the specification calls such values “floating”, explaining that a recipient “SHOULD interpret the value as being fixed to whatever time zone the ‘ATTENDEE’ is in at any given moment”. It then states the consequence without softening it: “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 is not one of those cases.
You will almost never produce a floating time yourself, because a calendar that knows your zone attaches it. 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 no matter which zone you look at it from.
So there is a ten second check worth making after the invitation goes out, and it is the last chance the error has to be cheap. Open the event and ask what it says in their clock. If that does not match 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 nobody is hunting for a joining link at 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 have known for years that New York is five hours behind London. For about four weeks a year that is false, and nothing announces it.
The dates differ because nobody coordinated them. The United States fixed its own in the Energy Policy Act of 2005, effective from 2007, and 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, that only ever agree by accident.
For a London and New York pair, that produced two windows in 2026.
- 8 March to 29 March. New York had sprung forward and Britain had not, so for three weeks New York was four hours behind London rather than five.
- 25 October to 1 November. Britain fell back first, so for one week New York was again four hours behind rather than five.
The same shape repeats in 2027, with the spring window running from 14 March to 28 March and the autumn one from 31 October to 7 November. The gap narrows in both windows, never widens, which is a small mercy and not one worth relying on.
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 is 10:00 there. Nobody has done anything wrong and no software has failed: an event stored against a zone recurs at the same local clock time in that zone forever, so it holds still for whoever created it and moves for everybody else. But somebody has to decide whether the meeting follows the organiser’s clock or the attendee’s, and if nobody decides, it follows the organiser’s by default 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 costs nothing. 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, and in the two windows when only one of the pair has changed it is ten. That is four changes a year and three different answers, and there is no version of it you can hold in your head.
The countries that never change, where the meeting moves anyway. This is the counter-intuitive 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. Nothing changed in India. The meeting moved twice regardless, and the person absorbing it is the one who never touched a clock. If you hold a standing meeting with somebody in a country that does not observe daylight saving, they are carrying the drift, and they may not have mentioned it.
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 20 September 2026. Europe has been about to abolish the change for years without doing it: the European Parliament adopted a position on 26 March 2019 supporting an end to seasonal clock changes, and the European Commission’s own page still records that “The Council has not yet finalised its position”, which leaves Directive 2000/84/EC in force (checked 19 August 2026). The practical reading is that 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 there is no convenient time, only a less inconvenient one, and choosing it 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, which means the window itself changes size at the changeover. London and Sydney share essentially none, which is why meetings between them happen at the edges 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” tells somebody what the shape of the problem is. “Mornings are better for me” does not, and invites a round of proposals that cannot land.
Decide who takes the awkward hour on purpose. The default is that whoever wants the meeting less ends up with it, 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 are rotating it so the other side knows the discomfort was noticed.
Consider whether the decision needs a live conversation at all. Across nine hours, a written answer that arrives while the other person sleeps is often faster than the earliest call either of you can stand.
For the case where somebody is simply picking a slot, a booking page removes this class of error from one whole side of the exchange, because it does the conversion at the moment of looking. Calendly’s own documentation describes the behaviour: it “detects your invitee’s time zone automatically” and shows availability in their local time, with a dropdown if the detection is wrong (checked 19 August 2026). That is the strongest argument there is for a link across a large gap. It is not the only consideration, and the judgment about when a link is the right instrument and when it reads badly is booking links that show real availability.
What a good habit here does not reach
Writing both clocks and naming cities closes most of this. It does not close all of it, and knowing the edges saves you from over-engineering the rest.
A person who has moved and not said. No convention catches a stale signature. Asking does, 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 is still correct and their day is not, and the only repair is somebody mentioning it. What happens next is when they ask to move a meeting, or, if you are the one moving it, moving a meeting.
Four zones on one invitation. There is no good hour, so there is a rota or there is a recording. Pretending otherwise produces a meeting that three people attend properly and one attends at eleven at night.
Whether you are free at all. A perfectly written time is still a guess if half your commitments live somewhere your main calendar cannot see, which is 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, and it holds the thread and the calendar in one surface rather than in two windows you copy between. For this subject that matters in a narrow, useful way: the check you would otherwise do in your head can be done against the event itself, while you are 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, so 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, at the moment you are 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. It is the ten second check described above, without the tab.
The rest of the arrangement runs on the thread. Say in plain words that a meeting needs setting up and Point checks your reconciled calendars, puts real times into the reply, and carries the correspondence from there, reading the answers in whatever words people used rather than requiring a format. It works across time zones, and it picks up a request to move something even 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 proper 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 whoever is looking at it.
Scheduling carries its own autonomy setting, separate from the rest of what Point does, and it starts on review. In practice that means the first few proposals and the first few invitations come past you before anyone else sees them, which is the right way to satisfy yourself that the zones are landing where you expect. Raise the setting when you have watched a few threads run; at the top of it the back and forth is handled outright. Point keeps an ordered record of what it did and undo works back through that record, with the ordinary limit that an invitation already sitting 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 3 September, 14:00 London time, which is 09:00 for you in New York.” Then say what you assumed. The second clock is not a courtesy, it is an error check performed by the one person who cannot get their own location wrong, and it surfaces a 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, and the eastern United States is not on Eastern Standard Time between March and November, so “3pm EST” in July is wrong if anyone reads it literally. Abbreviations are also not unique: 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, so it holds still for whoever created it and moves 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. Nothing is broken, but somebody has to decide whose clock the meeting follows, and by default it follows the organiser’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: 8 to 29 March, and 25 October to 1 November, during which New York was four hours behind rather than five. In 2027 the windows are 14 to 28 March and 31 October to 7 November.
Whose time zone should the meeting be in?
Yours for the invitation, theirs for the sentence. The event has to be created against one zone and the sensible choice is the organiser’s, because that is the calendar the meeting genuinely sits in and it is what everyone else’s calendar will convert from. The message around it should lead with their clock, since that is the number they will act on. What should be decided on purpose rather than by default is who takes the inconvenient hour when there is no good one.
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 can still be corrected cheaply. The invitation is the record and it is reliable: a properly formed event carries its zone and every recipient’s calendar renders it locally. But the invitation only goes out after a time has been agreed, and 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
The conversion is not where meetings get missed. Every calendar in the exchange does it 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, and an offset memorised 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, because 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, not the sentence, be the record, and spend ten seconds checking that the two agree.
The part that survives all of that is the changeover weeks, where the difference you have relied on for years is quietly wrong for somewhere between one and three weeks, and where 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 diary the warning rather than remember it. A consultancy arranging one-off calls has the opposite problem, which is that 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.