Change time zone in Google Calendar before the week shifts under you

The primary time zone gets changed, the page reloads, and every meeting in the week has moved. Nothing was edited, nothing was dragged, and yet Tuesday at ten is now Tuesday at three. The instinct is to change the setting back and never touch it again.

Nothing broke. Changing the time zone is supposed to do exactly that, because a Google Calendar event does not store a wall clock time. It stores an instant, and the grid decides what to call it. Understanding that one sentence turns time zones from a hazard into a tool, and it explains why some events move, some do not, and some move by an hour a few months later.

What the primary time zone changes, and what it does not

A timed event is stored as a moment on the world clock. When the calendar draws it, the moment is converted into whatever zone the account is currently set to. Change the zone and the conversion changes, so the drawing changes. The event itself is untouched, and anyone else looking at the same meeting in their own zone sees no difference at all.

This is the behaviour to want. A meeting agreed with a colleague in another country stays the same meeting whichever side is looking at it. If the calendar instead kept a wall clock time and left it alone, every trip would silently create a room full of people arriving an hour apart.

The setting lives in a browser, in the general section of Google Calendar's settings, and the value it accepts is a named zone from the IANA time zone database rather than an offset. That distinction matters more than it looks. A named zone such as Europe/Zurich carries the whole history of daylight saving changes for that place; an offset such as plus one hour does not. Choosing a named zone is what lets the calendar get next March right.

Changing the primary time zone is a display decision, not an edit. Nothing in the account is rewritten, so it is safe to change it back, and safe to change it as often as needed. What follows are the three cases where something other than pure display is going on.

All-day events never move, and that is by design

An all-day event is stored differently. It holds a date with no time and no zone at all, which means there is nothing to convert. A holiday on the fifteenth is the fifteenth from every zone on earth.

This is usually welcome and occasionally wrong. A deadline that is genuinely a wall clock moment, such as a submission that closes at midnight in one country, is the wrong shape as an all-day event. Anyone reading it from another zone sees the correct date and the wrong deadline. For those, a timed event carrying an explicit zone is the honest representation, even though it looks fussier on the grid.

The asymmetry also explains a common half broken week. After a zone change, timed meetings have shifted and all-day entries have not, so an all-day travel entry that used to sit above the right meetings now sits above different ones. Nothing is corrupted. The two kinds of entry simply answer to different rules, and the fix is to check that anything genuinely time bound is a timed event.

One more consequence is worth naming. Because an all-day event has no zone, it cannot be given one, and a calendar application that offers a time zone field per event will grey that field out for all-day entries rather than accepting a value.

Recurring events remember the zone they were created in

A single timed event can carry an optional time zone of its own, used for its start and end. A repeating event is different: the zone is required, and it defines the zone in which the repetition is calculated.

That sentence is the source of the most confusing time zone behaviour in any calendar. A weekly meeting created in one zone keeps repeating according to that zone's clock, including that zone's daylight saving dates. So a series set up in a country that moves its clocks in March, viewed from a country that moves them in November, will appear to jump by an hour for several weeks each year and then settle back. No event was edited. The series is simply being expanded somewhere else.

Two practical rules follow. A recurring meeting that should always mean local morning for the person who runs it belongs to that person's zone, and creating it while travelling bakes in the wrong zone for years. And a series that has drifted cannot be corrected by changing the account's primary time zone, because the series carries its own; the series itself has to be edited, or recreated.

For a single event the same field is optional and behaves as an override. Setting it makes the event mean nine in the morning in a named place, regardless of where the account is when it is read. That is the right tool for a flight, an appointment made while travelling, or a call fixed in a counterpart's zone.

One detail decides whether an event carries a zone at all. A stored start time needs either an offset attached to it or an explicit named zone; without one of the two, the value is ambiguous and the calendar has nothing to convert from. This is why an event created by pasting text, or imported from a file written carelessly, can land at a plausible looking hour and then refuse to move correctly afterwards. Events created in the interface always get one or the other, so the problem belongs to imports and to anything generated outside the calendar.

Four separate time zone settings, and which one to touch

Most wasted time comes from changing the wrong one of these.

Setting	What it affects	When to change it
Account primary time zone	How every timed event is drawn	A permanent move, or working in one place for a long stretch
Secondary time zone	An extra column of hours beside the grid	Regular work with one other region
Per event time zone	What a single event actually means	A flight, or a call fixed in another region's clock
Each calendar's own time zone	The zone used for events created in that calendar	Rarely, and only for a calendar dedicated to one region

There is a fifth that sits outside Google Calendar entirely: the time zone of the device. A Mac, a phone and a browser each ask the operating system what time it is, and a calendar application built for the desktop reads the system zone rather than the account setting. A laptop that has not updated its own zone after landing will show a correct account setting and a wrong day, which is the version of this problem that no amount of clicking inside a calendar will fix. The operating system's date and time settings are the first place to look when the two disagree.

Google also lets an administrator set a default time zone for new users across a domain, which is why a new work account sometimes arrives set to a country nobody in the team lives in. That default applies at creation and can be changed per account afterwards.

Why a secondary time zone usually beats changing the primary one

For anyone who works with one other region regularly, the secondary time zone is the setting that gets reached for too late.

It adds a second column of hours beside the grid in the day and week views, labelled with a name that can be typed in, and a tertiary zone can be added next to it for anyone working across three regions. Nothing else changes: events stay where they are, the primary zone still governs the grid, and no data is touched. Choosing a meeting slot becomes reading across rather than doing arithmetic.

A world clock is the lighter version of the same idea. It sits in the side panel as a list of current times rather than as columns on the grid, which suits checking whether it is a reasonable hour to call somebody more than it suits placing a meeting.

Compare that with the alternative people try first, which is changing the primary zone whenever attention shifts to the other region. That works, and it also renumbers the whole week twice a day, which makes it impossible to remember what a given block of time means. The mental cost is higher than the arithmetic it saves.

The secondary zone is also the better answer for short trips. A week away does not usually justify moving the account, because the events that matter during that week, such as flights and local appointments, are better handled with a per event zone. Keeping the primary zone at home and adding the destination as a secondary keeps both readable at once, and removes the risk of forgetting to change it back.

Where a desktop calendar helps is in how much of this is visible without opening a settings screen. Seeing the destination hours beside the home hours while a new event is being typed is the difference between catching a mistake and discovering it on the day, and the entry mechanics are described under Entering events. A calendar that also measures the route to a location will still compute travel in local terms, which is covered under Travel time.

Moving permanently, and the prompt that offers to help

For a genuine relocation, the account's primary time zone is the right thing to change, and there are a few checks worth doing on the same day.

Change the primary zone first, then look at the week and expect everything timed to have moved. That movement is confirmation, not damage.

Next, open any recurring series that is run rather than attended, and check the zone stored on it. Those are the events that will drift, because they expand in their original zone. A weekly one to one that should be local afternoon needs editing here, not in the account settings.

Then look at the all-day entries, since none of them moved. Anything that is really a deadline rather than a date is worth converting into a timed event with the correct zone attached.

Google Calendar can also offer to update the primary zone when it notices the device is somewhere else. Accepting that prompt performs the same change as doing it by hand, so it is a convenience rather than a different mechanism. The reason to decline it on a short trip is the one already given: the week stays readable when the primary zone stays home. The per event zone is available in the full event editor on both computers and phones, and it is the setting that carries an individual appointment correctly wherever it is read. What a Mac calendar can hold locally, and which parts need the browser, is set out in the Guide.

What to change first

Check the device's own date and time settings before touching anything in the calendar, because a laptop that never updated its zone produces the same symptom as a wrong account setting. Then add the region worked with most often as a secondary time zone rather than changing the primary one, and reserve the primary change for an actual move. For calendars read mostly on a Mac, seeing both zones and the travel time beside an event as it is typed removes most of the arithmetic, which is what a desktop calendar such as Caltimate is for.