Blog/Remote work
Published September 16, 2026

Managing Time Zones in Google Calendar for Distributed Teams

Google Calendar’s timezone machinery is genuinely good and almost entirely unconfigured on most accounts. This is the operator’s manual for distributed teams: the display setup, per-event anchoring, travel mode, the team conventions layer, and the recovery moves when times have already gone wrong.

Calendar Extension for Google Calendar™ Chrome extension showing upcoming events

The display layer: see two zones at once

Settings → Time zone: set your primary honestly (where your body is most weeks) and enable a secondary — the grid renders both hour-columns side by side, labeled ("Me", "SF team"). This one toggle deletes the per-meeting conversion habit for your dominant collaboration axis. Add the world clock (Settings → World clock) for the second and third axes: collaborator cities with their live local time in the sidebar, day-boundary flagged. Rule of thumb: secondary timezone for your main counterpart zone, world clock for the rest.

The anchoring layer: per-event timezones

Every event has a timezone, visible via the event editor’s "Time zone" link — and defaulting to your primary. Three cases where explicit anchoring matters: events hosted by another zone’s constraint (the client’s 9:00 board slot stays anchored to their zone so DST asymmetries move it correctly for you, never for them); travel events (the 14:00 Singapore keynote anchored to Singapore renders right on every device as you fly); and split-anchor events — the editor allows different start/end zones, built for flights ("dep 10:20 CET / arr 14:05 ET") so the calendar shows true local times at both ends.

Travel mode: the working-location handoff

Before a trip: add your travel dates to Working hours & location (colleagues’ find-a-time then shows you in the destination), consider whether to shift your working hours for the trip’s duration, and anchor trip events per-event as above. On arrival your device’s zone change re-renders the grid — which is correct and disorienting for about a day; the "Ask to update primary time zone" prompt is worth accepting for trips over a week, declining for short hops (constant primary-zone flapping confuses recurring events’ anchors more than it helps).

The conventions layer: what settings can’t do

Three team agreements complete the system. Zone-explicit proposals: every proposed time carries both zones in writing ("Thu 15:00 CET / 9:00 ET") — the ten seconds that prevents the classic off-by-an-hour meeting. A canonical team zone for shared artifacts: deadlines, release windows, and on-call handoffs get stated in one agreed zone (often UTC for engineering) regardless of who writes them. Working hours as a contract: everyone’s set, everyone’s honest, and the out-of-hours warning is treated as a stop-and-ask, not a click-through.

Recovery moves: when time already went wrong

The three common wrecks and their fixes. The meeting that moved an hour for half the attendees (DST gap window): open the series, check its anchor zone, re-anchor to the constraint-holder’s zone, and re-state the time in both zones in the description. The event that’s wrong on your phone but right on desktop: device zone settings disagree — set the phone to automatic zone and re-open. The recurring series created mid-travel that now lives in a random zone: edit series → Time zone → re-anchor home; the instances snap back. All three take two minutes once you know the anchor model — which is the actual content of timezone competence.

Between all the zone arithmetic, your own next commitment only ever needs one frame: local, now. The countdown chips in Calendar Extension for Google Calendar™ hold that frame in the toolbar — "in 40 min" is zone-proof — which quietly removes the last daily traces of conversion math.

Frequently asked questions

No — primary follows your body; the HQ axis belongs in the secondary column. Setting primary to HQ renders your entire grid in someone else’s frame, which reliably produces the exact off-by-hours errors it was meant to prevent. Bodies first, columns for the rest.

All-day events are date-anchored, not time-anchored — "March 14" stays March 14 in every zone, which is right for birthdays and deadlines-by-date and wrong for anything with a real clock time (a 23:00 release window needs a timed, zone-anchored event, or half the team celebrates a day early).

Device-local: a 10-minute reminder fires 10 minutes before the event’s true moment, rendered in wherever you are. The confusion cases come from events anchored wrong (see recovery moves), not from notifications — fix the anchor and the alerts follow.

For a small tribe (on-call engineers living in UTC-stated systems), yes, with eyes open: every human interaction then needs conversion. The wider-use version is UTC as the team’s canonical artifact zone while individuals keep body-local primaries — coordination clarity without grid alienation.

Related reading

Related: How to Schedule Across Time Zones Without the Chaos