Meeting organiser time zone: whose clock the invite is written in

An invite lands for nine in the morning. The first question is not whether that slot is free. It is whose nine in the morning it is, and the answer is almost never stated in the invite. The organiser's calendar settled that question when the event was saved, and everyone else inherited the result. For a one off call the consequence is a moment of arithmetic. For a weekly series it is a decision that will keep producing wrong answers twice a year for as long as the series exists.

An invite is stored once and displayed many times

The thing that makes time zones confusing in a calendar is that storage and display are separate, and only one of them belongs to the organiser. Google's own documentation for working across time zones states the display half plainly: an event appears in the creator's local time zone, and it also shows up in the local time zones of everyone invited, even when those people are somewhere else. Nobody has to convert anything by hand for a single meeting.

The storage half is where the organiser's setting matters. Events are converted to Coordinated Universal Time when they are created, and the local time on the grid is drawn back out of that stored value. So a single event is really an instant, and once that instant is fixed, every guest's calendar draws the same instant against a different set of hour labels. Change your own time zone and every event on the grid moves together, because the instants did not change and the labels did.

That is why a guest who fixes a display problem never fixes a scheduling problem. Switching a laptop from one zone to another, or turning on a second column of hours, rewrites nothing. The only person who set the anchor was the organiser, at the moment of saving, using whatever zone their calendar was in. The rest of this comes down to knowing which of those two halves a given symptom belongs to.

The organiser's time zone lives in four separate places

There is no single setting called the organiser time zone. There are four, they are edited in different screens, and they have different reach. Two of them change data and two of them change only what is drawn.

Where it lives	What it governs	Who can change it
Account primary time zone	The zone new events are created in and the hours drawn on the grid	The account holder
A single calendar's time zone	The zone that calendar's events are interpreted against	Only the owner of that calendar
The time zone on one event	The zone that event's start and end are anchored to	Whoever can edit the event
Secondary and tertiary zones, world clock	Display only, extra hour columns and a list of current times	Each viewer, for themselves

The per calendar setting carries a restriction that catches people out. Google states that a person who is not the owner cannot change the time zone of a calendar. Anyone who has inherited a shared team calendar from a colleague in another country has met this: the calendar keeps interpreting new events against a zone nobody in the room lives in, and no amount of fiddling with personal settings touches it.

The per event zone is the precise instrument. Google Calendar lets a zone be chosen next to the event time, and it also allows separate start and end zones for anything that crosses a boundary, such as a flight. For a one off event this is optional and simply pins that event to somewhere else's clock. For anything repeating it stops being optional, which is the next section.

A recurring series is expanded in one time zone

A repeating meeting is not a list of instants. It is a rule, and a rule has to be unrolled against a clock before it becomes instants at all. The Calendar API is explicit about which clock that is.

The time zone in which the time is specified. For recurring events this field is required and specifies the time zone in which the recurrence is expanded. For single events this field is optional and indicates a custom time zone for the event start/end. Source: developers.google.com

Required, and singular. One zone governs the whole series, it is chosen when the series is created, and in practice it is the organiser's own zone because that is the default. Everything that follows from that is not a bug. A weekly call created in Tokyo keeps its Tokyo hour forever. In London and in New York the same call moves around, because those places move their clocks and Tokyo does not.

This is also why editing one occurrence never cures a drifting series. The occurrence is an exception layered on top of the rule, and the rule is still being expanded in the original zone. The series has to be recreated, or the zone on it changed, for the underlying behaviour to change.

Anything that creates events from typed or spoken text has to resolve the same question before saving, because a phrase such as every Tuesday at nine carries no zone at all. The Entering events part of the guide covers how a parsed phrase gets anchored, which is worth reading before trusting quick entry with a cross border series.

What changes when the clocks move

Twice a year, on weekends that differ by country, a series that looked settled for months produces a meeting half the guests miss. The behaviour is specified rather than arbitrary. The iCalendar standard that all of these systems exchange events in states what a local time means when the clocks make it ambiguous.

If, based on the definition of the referenced time zone, the local time described occurs more than once (when changing from daylight to standard time), the DATE-TIME value refers to the first occurrence of the referenced time. Source: rfc-editor.org

The standard gives the matching rule for the other direction. When the described local time does not exist, which is the hour skipped going into daylight time, the value is read using the offset from before the gap. Recurrence instances that land on an ambiguous or missing local time are resolved the same way.

Two practical consequences follow. First, the organiser's country is the only one where the hour holds still, so the organiser is the last person to notice the drift. Second, the transitions do not line up between regions. North America moves its clocks earlier in the spring than Europe does, which leaves a stretch of weeks each year when the usual gap between them is one hour smaller than everyone has memorised. Google also warns that events far in the past or the future may not reflect a change correctly, and that events created before a country announced a change can sit in the wrong zone entirely.

What a guest can and cannot do about it

A guest has real options, but all of them are on the display side. The calendar can show additional time zones alongside the primary one, as a second and a third column of hours down the left of the grid, which makes an eleven o'clock block readable in two places at once without opening anything. A separate world clock setting lists current local times for chosen cities, which answers a different question: whether it is reasonable to send a message right now, rather than what a block on the grid means to someone else.

Google also offers to confirm the primary zone on arrival somewhere new, through a setting that asks to update the primary time zone to the current location. That is worth turning on for anyone who travels, because the failure it prevents is the worst kind: a grid that looks normal and is uniformly wrong.

One thing does move when a guest changes zones, and it is easy to miss. Tasks follow the calendar's zone rather than staying put. Google's example is a nine in the morning Mountain Time task becoming an eleven in the morning Eastern Time task when the traveller goes from Denver to New York. Events keep their instant, tasks keep their wall clock hour. Anyone who schedules work in task form and meetings in event form will see the two slide past each other after a flight.

What a guest cannot do is change what the series means. That is the organiser's setting, and the only route to it is asking. Worth knowing before asking: the organiser usually has no idea there is a problem, because in their country nothing moved. Sending the specific dates on which the meeting landed in the wrong slot makes the request concrete, and it is far more effective than describing the drift in the abstract.

Deciding who should own a cross border series

Because the zone follows the organiser, the choice of organiser is a scheduling decision rather than an administrative one. Three patterns hold up.

Anchor the series to the place that defines it. A market open, a shift handover, a broadcast, a store closing: these are local facts about one place, and the person in that place should own the series so the hour never drifts there.

Anchor it to the least flexible side. When one group has hard constraints, such as a factory or a clinic, and the other can absorb an hour of movement, the constrained side should own the series. The drift then lands where it can be handled.

Rotate ownership when the cost is genuinely symmetric. Two teams eight hours apart cannot both meet inside working hours. Splitting the series, one owned on each side, distributes the early mornings and late evenings instead of concentrating them on whoever happened to send the first invite.

Whatever the pattern, put the zone in the event title or description in words. The calendar will render the block correctly for everyone, but the invite is also read in email, in chat and on phones, and plain text survives all of them. Naming the city rather than the abbreviation is better still, since Asia/Tokyo and Europe/London are unambiguous while abbreviations such as CST are used for more than one offset.

One more habit reduces the damage when a series does drift. Keep cross border series shorter than the interval between clock changes, and recreate them rather than letting a single rule run for years. A series that is rebuilt each quarter gets its zone reconsidered each quarter, at a moment when someone is looking at it, instead of silently expanding against a decision made once and forgotten.

What to change first

Start by finding out which zone the recurring meetings in the calendar are actually expanded in, because that is the setting producing the twice yearly surprises and it is invisible until it is looked for. Then turn on a second column of hours so every block can be read in the other side's clock without arithmetic. A Mac calendar that shows both rulers on the grid and states the zone when an event is created removes most of the remaining guesswork, and the Features page and Caltimate both set out what that looks like in practice.