Google Calendar assistants: avoid time-zone mistakes

If you schedule meetings between Paris and Dakar, a poorly designed Google Calendar assistant can shift every slot by an hour, and that shift changes with the season. On October 20, 2026, 10 a.m. in Paris corresponds to 8 a.m. in Dakar; on November 3, 2026, the same 10 a.m. Paris time corresponds to 9 a.m. in Dakar. The difference does not come from Dakar, which stays on UTC+0 all year, but from Paris switching to winter time. This design guide explains where these mistakes originate and which controls to put in place.

Why Paris/Dakar exposes design flaws

Paris and Dakar have different relationships to universal time. Dakar follows UTC+0 permanently: no daylight saving, no switch. Paris follows a daylight saving rule: UTC+2 in summer, UTC+1 in winter. Between two meetings a few weeks apart, the Paris/Dakar offset can therefore go from two hours to one.

For an appointment scheduling assistant, this means that reasoning in "local hours" without an explicit zone produces events that are correct in October and wrong in November, even though nothing changed in your logic. The mistake does not appear during development: it appears after the clock change, when your participants notice an hour's shift on their invitations.

Use IANA zone identifiers, never fixed offsets

The first design rule: your assistant must store and transmit IANA zone identifiers — Europe/Paris, Africa/Dakar — rather than offsets like "UTC+2". A fixed offset freezes a situation that changes twice a year for Paris. An IANA identifier delegates the calculation to a maintained rule base, which knows that on October 20, 2026 Paris is on UTC+2 and on November 3, 2026 on UTC+1.

Concretely, every time handled by your calendar automation must carry three distinct pieces of information: the date, the time and the zone. As soon as one is missing, your assistant is tempted to guess it, and that guess is what creates the mistakes. You can verify these conversions with zone tooling (zoneinfo in Python, equivalents elsewhere) before each seasonal switch: take two dates, one on either side of the change, and check that the computed offset matches what participants will see in their calendars.

The textbook case: two 10 a.m. meetings a month apart

Let's take a deliberately simple main example. A Paris-based practice works with a provider in Dakar and sets two follow-up sessions, both "at 10 a.m. Paris time".

Meeting	Requested time	Reference zone	Time in Dakar	Paris/Dakar offset
Session 1	Oct 20, 2026, 10 a.m.	Europe/Paris (UTC+2)	8 a.m.	2 hours
Session 2	Nov 3, 2026, 10 a.m.	Europe/Paris (UTC+1)	9 a.m.	1 hour

If your assistant reasons in "UTC+1" end to end, session 1 will be created at 9 a.m. in Dakar instead of 8 a.m. If instead it freezes the offset at two hours, session 2 will be created at 8 a.m. instead of 9 a.m. In both cases the calendar shows a plausible event, which makes the error hard to spot before the day itself.

The useful control is therefore a conversion check before creation: for each slot, your assistant computes the time in the remote participant's zone and compares it with the stated intent ("10 a.m. Paris"). If the two diverge, the booking is held for review rather than confirmed automatically.

Ambiguous dates: date only, all-day events and the clock change

Time-zone mistakes are not limited to timed slots. Three situations deserve explicit handling.

The bare date. When a participant writes "November 3", they express a date without a time. Your assistant must not invent 9 a.m. or 10 a.m.: it should ask for a time, or propose slots drawn from real availability. A date alone is not a meeting.

All-day events. Google Calendar supports "all-day" events, defined by date rather than by instant. This is often the right choice for a deadline or a trip, but be aware that an all-day event can display across two days for a participant in a far-offset zone. For a working meeting between Paris and Dakar, a time-stamped slot with a zone remains safer than an all-day entry.

Instants near the clock change. A meeting scheduled on the night of the switch deserves a specific check: the computed end time in the new zone can look inconsistent while being correct. This is a rare case, but it is precisely the one automated tests forget.

Never treat the browser time zone as the truth

Many booking tools infer the participant's time zone from their browser. That is convenient for display, but it is a fragile basis for decisions. A participant who is travelling, uses a VPN or has a misconfigured device may present a zone that does not match their reality. For an appointment scheduling assistant, the browser zone is a display hint, not a booking datum.

Sound design separates two uses: display, where you convert times into the detected zone to aid reading; and booking, where the reference zone is chosen explicitly — the practice's zone, the participant's zone confirmed in conversation, or a declared business rule. When two zones are in doubt, explicit confirmation wins over automatic detection.

Define the source of availability before booking

A frequent time-zone error comes not from the calculation but from the source: the assistant checks the availability of a calendar whose events are defined in a different zone than it assumes. If your practice works in Europe/Paris but the assistant reads slots from a secondary calendar set to UTC, every proposed slot will be shifted.

Before any automation, document three choices: which calendar is authoritative for availability, in which zone its times are defined, and who may book on it. These choices also underpin double-booking prevention, because the same range seen in two different zones can look free while it is taken. When creating events through the API, the official event creation documentation describes how to pass the event's time zone: that declared zone governs what participants see, which is why it should be set deliberately rather than left to a default.

Display to the participant: convert without deciding for them

The Dakar participant should see "8 a.m. (Dakar)" for a 10 a.m. Paris meeting in October, and "9 a.m. (Dakar)" for the same 10 a.m. Paris time in November. Localized display is a service, provided it remains a conversion and not a redefinition of the meeting.

Three practices reduce misunderstandings:

• Always show the time in the meeting's reference zone, then the conversion into the participant's zone, with a readable zone name (not just an offset).
• Flag meetings close to a clock change: "note that between booking and the meeting, France moves to winter time".
• Keep the participant's original wording ("10 a.m. Paris") in the conversation as a record of intent, so you can arbitrate in case of dispute.

A booking journey without dead ends assumes the participant can verify the time in their own zone before confirming, not after.

Confirm explicitly before creating the event

Explicit confirmation is your last line of defence. Before creating the event, the assistant restates the slot with its zone: "Meeting on November 3, 2026 at 10 a.m. Paris time, i.e. 9 a.m. in Dakar. Shall I book it?" This restatement costs a few seconds and removes most offsets, because it forces the conversion to be shown rather than assumed.

This step ties in naturally with upstream qualification: an agent that qualifies the request before booking can raise the time-zone question in the initial exchange ("do you confirm the time is expressed in Paris time?"), avoiding a surprise at confirmation stage. After confirmation, any time change must go through the same restatement: the rules for rescheduling and cancelling apply to the time zone too, not just the date.

A control procedure before each seasonal switch

Here is an actionable procedure to run twice a year before the European clock change:

1. List the zone rules in force. Note each stakeholder's IANA identifier and daylight saving rule (Paris switches; Dakar does not).
2. Pick two test dates. One before the switch, one after — for example October 20 and November 3, 2026.
3. Compute the expected conversions. With zone tooling: 10 a.m. Paris = 8 a.m. Dakar on October 20; 10 a.m. Paris = 9 a.m. Dakar on November 3.
4. Test the full journey. Have the assistant book a dummy slot on both dates and check the time displayed for each participant.
5. Check existing events spanning the switch. Confirm that meetings already planned after the change remain correct in both zones.
6. Document the result. A short note is enough: dates tested, expected conversions, discrepancies found.

This procedure is a design recommendation, not an obligation: its value is turning a seasonal risk into a repeatable control.

Limits and classic mistakes to own up to

No design removes every risk, and it is better to name them. A correct IANA zone does not protect against wrong human input: if the participant says "10 a.m." thinking of Dakar while the practice's rule is "Paris time", only the human exchange catches it. Zone identifiers also evolve over time: countries' rules can change, which justifies keeping zone databases up to date rather than hard-coding offsets.

Finally, explicit confirmation has an experience cost: it adds an exchange. For an internal meeting with no time-zone stakes, it can be lightened; for a cross-border meeting, it should never be. That is a design decision per meeting type, not a single rule.

Frequently asked questions

Should we store times in UTC in our system?

Storing in UTC is sound practice for instants, provided you also keep the meeting's reference zone. UTC alone is not enough: it does not tell you how to display "10 a.m. Paris" to a participant, nor how to reason about a business rule expressed in local time.

How do we handle a participant who travels between booking and the meeting?

The meeting's reference zone does not change because the participant moves. Show them the time in the reference zone and let their calendar convert to wherever they are; offer to reschedule only if they ask.

What if our assistant does not know the participant's zone?

Ask for it explicitly, or propose slots expressed in the practice's reference zone with a clear conversion. Never infer the booking zone from the browser alone: it is a display hint, not reliable data.

Do all-day events avoid these problems?

They avoid part of them, since they are defined by date, but they create others: an all-day event can display differently depending on the participant's zone, and it does not suit a timed meeting. For Paris/Dakar, prefer a slot with an explicit zone.

How often should we test time-zone conversions?

Twice a year is enough for the European switch, plus tests whenever the assistant evolves or a new zone is added. The key is to include dates on either side of the clock change, like October 20 and November 3, 2026 in our examples.