Your client is in another time zone. Whose 9am is in the reminder?
The client did not show up. The reminder had gone out, they had read it, and they had put it in their calendar. It said nine, and at nine they were sitting somewhere three hours away from where you were waiting.
Nobody made a mistake anyone could point at. The booking was correct in your calendar. The reminder was correct in your calendar's terms. It just never said whose nine o'clock it meant, and the client had no reason to think the question existed.
This is a different fault from a schedule that drifts after the clocks change. That one moves your automation. This one moves your client, and it happens on ordinary days, to bookings made months apart, and only ever shows up as a no-show that nobody can explain.
Whose clock does the reminder actually speak in?
Almost always the one belonging to the calendar, which means yours.
GReminders documents this behaviour plainly in its own help pages: "Typically the meeting is booked in your local time zone. So lets say you live in California and you book a meeting for 9am Pacific. If your client is in New York, they may get a reminder that the appointment is at 9am instead of 12pm." That is the vendor describing its own default, not a customer complaining. The fix it points to is to book the event in the client's time zone, after which, in its words, "the reminder that is scheduled to go out is set to the CUSTOMER's time."
Read that twice, because the shape of it matters. Nothing failed. No error was logged, no integration broke, no message bounced. The system did exactly what it was told, using the only clock it had been given, and produced a message that was true for you and false for the person reading it.
That is the whole category. Reminders in the wrong time zone are not delivery failures. They are correct messages about the wrong moment.
The three ways a booking tool arrives at the wrong hour
It helps to know which of these is happening to you, because the fixes are different.
It guessed from the device. Calendly's own troubleshooting guide says it works out the time zone from your device settings and synced calendars. Guessing from a device is right most of the time and wrong in exactly the situations small businesses run into: a client on a VPN, a laptop still set to the country they moved away from, a phone that updated while the desktop did not.
It fell back to UTC. The same guide is direct about what happens when the signals disagree: when Calendly "can't or receives conflicting information," it "defaults to UTC." It also notes this is especially common with Hotmail, Yahoo and AOL addresses, which "default to UTC." If your clientele skews toward older consumer email domains, this is not an edge case, it is a segment.
Somebody locked it. When a host locks the time zone, invitees see the times in the host's zone regardless of where they are. This one is often deliberate — it is genuinely the right setting for an in-person appointment, where the only clock that matters is the one on the wall of the room. It becomes a trap when the same setting is inherited by a video call with someone abroad.
The first two are the system being unsure. The third is the system being sure and being wrong for that particular booking.
The setting you changed was not the setting you meant
Here is where owners lose an afternoon. They find the time zone setting, fix it, test it, and the problem continues, because the product has more than one.
Microsoft documents this for Bookings without any hedging: "There are two separate language and time zone settings for Bookings. The first setting controls the language and time zone of the booking calendar and is set using the Outlook on the web settings for the personal calendar of the logged-in user. The second setting affects the self-service booking page that your customers use and is set using a 'regional settings' page that controls language and time zone only for that page."
So the page your customer looks at, and the calendar your staff look at, are governed by two different controls in two different places. Worse, the calendar one is inherited: "The booking calendar uses the logged-in user's language and time zone settings [...] This time zone was originally set when the user's Microsoft 365 and Outlook on the web accounts were created."
Set when the account was created. Not when the business moved, not when the person relocated, not when a new receptionist took over a mailbox that used to belong to someone in another country. A decision made once, years ago, by whoever clicked through the setup screen, is still deciding what time your customers are told to arrive.
If you have ever fixed a time zone and watched the problem survive, this is usually why: there was a second one.
The four weeks a year when the gap moves under you
Even with every setting correct, the distance between two countries is not a constant. It changes four weeks a year, and not on the same weekend.
The United States, per NIST, starts daylight saving "at 2:00 a.m. on the second Sunday of March" and ends it "at 2:00 a.m. on the first Sunday of November." The United Kingdom, per gov.uk, puts "the clocks go forward 1 hour at 1am on the last Sunday in March, and back 1 hour at 2am on the last Sunday in October."
Two rules, different Sundays. Apply them to this year and the windows fall out:
| Window in 2026 | What has happened | Effect |
|---|---|---|
| 8 March – 29 March | US has moved, UK and EU have not | Gap is one hour smaller than usual for three weeks |
| 29 March – 25 October | Both on summer time | Normal gap |
| 25 October – 1 November | UK and EU have moved back, US has not | Gap is one hour smaller than usual for one week |
Four weeks a year, then, a standing 9am call with a London client is not the call you think it is. Systems that store the booking properly handle this on their own. The place it bites is everything stored as a bare number: the recurring appointment somebody typed in as "2pm every second Tuesday", the opening hours in a spreadsheet the reminder template reads from, the note in the CRM that says "always books mid-morning".
It also bites the mental arithmetic. Staff who have learned that a client is "five hours ahead" will be wrong for four weeks and will not know which four.
What to check, in the order that finds it fastest
Send yourself a reminder as a client in another zone. Not a preview — an actual booking, made from a device set to a different country, delivered to an address you can open. Previews render in your session, with your settings, which is precisely the thing you are trying to test around.
Then check the same booking in four places. The booking page, the confirmation email, the calendar invite attachment, and the SMS if you send one. These are frequently generated by different components, and it is normal to find three of them right and one wrong.
Look for a second time zone setting. If the product has a booking page and a staff calendar, assume the two are configured separately until you have seen otherwise.
Find the bookings that were typed rather than booked. Recurring appointments, standing calls and anything entered as text are the entries that will not survive a shift in the gap.
Write the reminder so the question cannot arise
Most of this stops mattering if the message answers the question by itself.
State the zone every time, spelled out rather than abbreviated: "10:00 in London (BST)" beats "10:00 BST", which beats "10:00". Abbreviations are ambiguous in ways people do not expect — there is more than one CST in the world, and your client may not be thinking about which one you mean.
Give both clocks when you know both: "14:00 your time / 09:00 ours". It costs a line and removes the entire class of error, including the four-week windows, because a client who sees two numbers that do not match their expectation will ask before the appointment rather than after it.
Put the time in the calendar attachment, not only in the body of the email. Calendar files carry the zone as data, which is exactly what a phone needs to render the right local time. An email body is text, and text does not convert itself.
And when someone confirms, notice what they confirm with. A client who replies "see you at nine" to a message that said ten has just told you, for free, that something is wrong — but only if anyone is reading the replies closely enough to catch it.
When it is worth going further than settings
For a practice with one calendar and local clients, the checks above are the whole job, and an afternoon closes it.
It stops being that when the appointment is one step in something longer: a booking that triggers an intake form, a deposit, a document to sign, a reminder sequence, and a follow-up. Each of those steps has its own idea of what time it is, and they are not obliged to agree with each other. The no-show is then not a calendar problem at all — it is a sequence where the second step was scheduled off the first step's misunderstanding.
Working out which of your steps carry a real time zone and which are carrying a number somebody typed is one of the things a process audit is for. $299, three business days, and it ends with a list of where your process actually loses people rather than a guess.
Sources
I read these pages in August 2026. Vendor documentation moves; check the vendor's own page before acting on it.
Whose clock a reminder uses by default: GReminders on sending reminders in client time zones.
Two separate settings in one product, and where the calendar's zone comes from: Microsoft on Bookings language and time zone settings.
How a booking tool detects a zone, and what it does when the signals conflict: Calendly's time zone troubleshooting guide.
The two transition rules the table is derived from: NIST on US daylight saving time and gov.uk on when the clocks change.
Related: why your 8am automation runs at 7am after the clocks change covers the other half of this — what a clock change does to a schedule rather than to a message.