Google Calendar time zone is wrong: which setting moved your events

A meeting that was set for 10:00 is sitting at 03:00. Nothing was edited, nobody rescheduled, and the clock in the menu bar is correct. When the Google Calendar time zone is wrong, the instinct is to open the event and drag it back, which is the one move that guarantees the problem returns. The event is not in the wrong place. It is being displayed through a setting that no longer matches the situation, and there are four candidates for which setting that is.

Four different time zones are in play at once

A single event on a Mac passes through several independent zone settings before it reaches the screen. Each one can be wrong on its own, and each produces a slightly different symptom.

There is the operating system's zone, set in System Settings on the Mac. There is the account's primary time zone in Google Calendar, which is what the grid is drawn in. There is a per calendar zone, because an individual calendar inside the account can carry its own. And there is a per event zone, stored on the event itself, which is what makes an event look immovable while everything around it shifts.

Google's own documentation on using Google Calendar in different time zones describes the layers and is worth having open while working through them. The important sentence in it is about how events are stored: to avoid problems with daylight saving time, Google Calendar uses Coordinated Universal Time. Events are converted into UTC when they are created, and always displayed in local time.

That single design choice explains most of what follows. The stored moment does not move. The lens does. So the question is never "what happened to the event" but "which lens changed".

It also explains why editing the time of a misplaced event is the wrong repair. Dragging a 03:00 entry back to 10:00 while the calendar is drawn in the wrong zone writes a new stored moment, and once the zone is corrected the event lands three hours from where it belongs, in the opposite direction. Anyone who has repaired a week this way has usually repaired it twice. Correct the lens, confirm that the events fall back into place on their own, and only then edit the handful that genuinely need editing.

The primary time zone is the one that moves everything

If every event in the calendar is off by the same amount, the primary time zone is the setting to check, and it is the only one worth changing first. It lives in Google Calendar on the web, under Settings, then General, then Time zone, where the field is labelled Primary time zone and takes a city or country rather than an offset.

Two things about that field cause trouble. The first is that it is searched by place, not by abbreviation, so a country with several zones has to be narrowed by city. The second is that it can be changed without the person noticing, because of the setting directly beneath it: Ask to update my primary time zone to current location. Turned on, Calendar offers to move the whole grid when travel is detected. Accepting that offer on a short trip and forgetting about it is a common way to arrive home with every meeting an hour or five out.

A calendar inside the account can also carry its own zone. Google documents the path as the My calendars list, then Settings and sharing on the calendar in question, then Time zone. This is the setting behind a symptom that looks impossible: work meetings correct, a shared project calendar consistently off. The documentation is explicit that someone who is not the owner cannot change the time zone of a calendar, so on a calendar shared by a colleague the fix has to happen at their end.

Reading the symptom back to the setting

Matching what appears on screen to the layer that produced it saves the trial and error of changing settings in sequence.

What the calendar shows	The layer most likely responsible	Where to look
Every event shifted by the same amount	Account primary time zone	Settings, General, Time zone
One calendar shifted, the rest correct	That calendar's own zone	Settings and sharing for that calendar
One event stuck while others are fine	Zone stored on the event	Edit the event, then Time zone
Only the menu bar clock disagrees	The Mac's own date and time	System Settings, General, Date & Time
A repeating event drifts by an hour twice a year	Daylight saving time	Nothing to fix, see below
Shifted only during a trip	The travel prompt was accepted	Settings, General, Time zone

The fifth row is the one most often mistaken for a fault. Google's documentation notes that events in past years, or well into the future, might not reflect daylight saving time changes and might be displayed incorrectly, and that as the date moves closer the displayed time adjusts automatically. An event two years out that looks an hour wrong today will often be right by the time it matters.

An event stuck in a zone of its own

Google Calendar stores a zone on each event, which is why one entry can hold its ground while the rest of the week moves. The path to change it is to click the event, choose Edit, then click Time zone next to the event's time and search for the city or country.

This is also where an event gets its zone in the first place, whether or not anyone chose it. Creating an event through Create, then Create event, then More options exposes the Time zone control at creation time. Anything created quickly, without opening the full form, inherits the zone that was current at the moment of creation. Events created during a trip, or during the window when the travel prompt had been accepted, are the usual source of a single stubborn entry.

There is a second control on the same panel that solves a genuinely awkward case. Google documents Use separate start and end time zones, for an event that begins in one zone and ends in another. A flight is the obvious example, and writing it with a single zone is what produces a booking that appears to last either eleven hours or negative two.

Why the shift is so often exactly one hour

An offset of exactly sixty minutes, appearing on a specific date and not before, is almost always daylight saving time rather than a misconfigured setting. Because Calendar stores the moment in UTC and renders it locally, a change in local offset moves the rendered time while the stored moment stays put. For a one off meeting that is correct behaviour. For a recurring meeting across two countries that change clocks on different dates, it produces a window of a few weeks each year where one side is an hour out.

Google names a related case that no amount of local configuration will fix: if an area changes its time zone, events created before that change was known can end up in the wrong zone. Government decisions about offsets propagate into time zone databases, and events written before the update carry the old assumption. The remedy is to recreate the affected events rather than to hunt for a setting.

For anyone who schedules across zones regularly, the working fix is not a setting but a reference. Google documents two: additional time zones, which puts a secondary and a tertiary zone as extra rulers on the left of the calendar grid, and a world clock, added under Settings in the World clock section. Both remove the mental arithmetic that produces the errors in the first place. A native calendar on the Mac that keeps those references visible without a browser tab is doing the same job, and Compared with other calendars sets out how the desktop options differ on this point.

Travelling, and what the calendar does to tasks

The travel prompt deserves its own note because it touches more than events. Google's documentation states that tasks adapt to the new time zone if the calendar's time zone is changed after the task was created, and gives a concrete example: a task at 9 AM Mountain Time becomes an 11 AM Eastern task after a move from Denver to New York.

That is sensible for a task like a stand up meeting and wrong for a task like taking medication. Events behave differently again. An event keeps its stored moment and is displayed in the new local time, so a 10:00 call in Tokyo correctly appears at 03:00 after a move to London. Both behaviours are consistent, and neither is what people expect while packing.

Invitations add a third behaviour. An event created in one zone and sent to attendees in another is shown to each of them in their own local time, without anyone converting anything. That is the case that works well by default, and it is worth remembering before adding the zone into the title of a meeting. Writing the hour into the title is a habit carried over from email, and it introduces a second source of truth that goes stale the moment the meeting is moved.

The practical choice is between two habits. Leaving the travel prompt on and accepting it means the grid always matches the wall clock, at the cost of every task quietly moving. Leaving it off means doing the conversion in the head, at the cost of arriving at a meeting an hour late once. For frequent travel, turning it on and putting a secondary zone for home on the grid gives both the local view and the reference point.

What the Mac itself contributes

If the clock in the menu bar is also wrong, none of the Calendar settings above will produce a correct result, because the browser and the desktop calendar both read the system zone. Apple's guide to setting the date and time on a Mac gives the path as System Settings, then General in the sidebar, then Date & Time, with two controls worth confirming: Set time and date automatically, and Set time zone automatically using your current location.

The second one is the one to look at on a machine that travels. With automatic zone detection on, the Mac follows the network, which is usually right and occasionally is not, most often on a VPN that terminates in another country. With it off, the Mac keeps whatever zone was last set, which is predictable and needs a manual change after each trip. Neither is better in general, but knowing which of the two is active turns a mysterious offset into a one line explanation.

What to change first

Check the Mac's clock, then the account's primary time zone, then the zone on the single event that will not behave, in that order. Then decide the travel prompt question deliberately rather than answering it on an airport connection. A calendar that shows a second zone next to the first, and that files travel between meetings as its own block, removes most of the conversions where these mistakes are made: Caltimate takes that approach on the Mac, and the rest of the behaviour is documented under Guide.