Change the timezone in Google Calendar without changing event times

The setting is changed, the page reloads, and every meeting has moved. The 09:00 standup is now at 02:00. The dentist is in the middle of the night. Nothing was rescheduled and nothing is broken, and yet the calendar is unusable until the setting is put back.

The request behind the search is reasonable: move the clock the calendar is drawn against, leave the events where they were. Google Calendar cannot do that for timed events, and the reason is in how events are stored rather than in a preference that is hidden somewhere. Once that is clear, the question changes into a more productive one, which is which of these events were ever anchored to a wall clock in the first place.

What Google Calendar actually stores

An event does not hold the text "09:00". Google's documentation on using Calendar in different time zones states that events are converted into Coordinated Universal Time when they are created, and that you always see them in your local time. The stored value is a moment. The time on the grid is a rendering of that moment against whatever zone the calendar is currently set to.

That single design decision explains every symptom. Changing the primary time zone does not touch a single event, because there is nothing in the event to touch. It changes the lens. The standup that was created as 09:00 in a zone nine hours ahead of UTC is stored as 00:00 UTC, and viewed from a zone two hours ahead of UTC it is 02:00. Both readings are correct and describe the same instant.

The same documentation is explicit about what invited people see: an event appears in the local time zone of everyone invited, even when they are in a different zone. The calendar is doing the conversion for every viewer at once, which is exactly the behaviour anyone scheduling across countries wants, and exactly the behaviour that makes "keep the times" impossible as a global setting.

"Keep the times" is two separate requests

The phrase covers two intentions that need opposite handling, and separating them resolves most of the confusion in one step.

The first intention is that the event should still happen at the same absolute moment. A call with a colleague in another country was agreed for a specific instant, and it stays at that instant regardless of where either party is sitting. For these, the correct action is to do nothing. Change the display zone, accept that the number on the grid is different, and the appointment is still right.

The second intention is that the label should stay put. Breakfast is at 08:00 wherever you are. The gym session is at 07:00 local. A daily review is at the end of the working day, whichever working day that is. These were never anchored to a moment in UTC. They were anchored to a wall clock, and the calendar has no concept of that for a timed event.

What the event is	Behaviour wanted	What to do
A call agreed with other people	Same instant everywhere	Nothing, let it convert
A local routine such as a gym slot	Same number on the clock	Recreate it after arriving, or make it all-day
An appointment at a fixed location	Same instant, in that place's zone	Set the time zone on the event itself
A flight	Departure in one zone, arrival in another	Separate start and end time zones
A deadline with no hour attached	Ignores zones entirely	All-day event

The last row is the most useful and the most overlooked. An all-day event has no time, so it has no zone to convert, and it stays on the same date whatever the grid is set to.

The four places a time zone can be set

There are more levers here than the settings screen suggests, and they operate at different scopes.

The primary time zone sits under General, then Time zone, in Google Calendar's settings, and it is the one that redraws everything. In the same place is an option to have Calendar ask about updating the primary zone when you arrive somewhere new, which is worth turning on purely so the change is a deliberate answer to a prompt rather than a surprise.

A single calendar can carry its own zone. Open My calendars in the sidebar, then Settings and sharing for that calendar, then Time zone. Google notes one restriction on this: the time zone of a calendar cannot be changed by anyone who is not its owner. A separate calendar for one location, with its own zone, is the tidiest way to keep a set of events anchored to that place.

A single event can carry its own zone. While editing an event, click the time zone control next to the time, and pick a city or country. The same control offers separate start and end time zones, which is what a flight, an overnight shift or a cross-border train actually needs. This is the setting that answers the original question for the events that matter most, because it survives every later change to the primary zone.

Finally, two settings change what is shown without moving anything. A secondary and a tertiary time zone can be displayed as extra columns down the left of the grid, and a world clock can be turned on in settings with as many cities as needed. Where the goal is to read two zones at once rather than to switch between them, these are the right tools, and neither touches a single event.

All-day events and tasks follow different rules

All-day events have no time component, so there is nothing for the conversion to act on. Moving a calendar from one side of the world to the other leaves them on the same dates. For anything that is a date rather than an appointment, a deadline, a birthday, a travel day, an all-day event is both simpler and more robust than a timed one.

Tasks behave differently again, and the behaviour is documented with an example. Google states that tasks adapt to the new time zone if the calendar's time zone is changed after the task was created, and gives the case of a 9 AM task in Mountain Time becoming an 11 AM task in Eastern Time for someone travelling from Denver to New York. So tasks move in the same direction as events. Anyone who relies on a dated task list through a time zone change should expect the times to shift and should check the first day after the change.

One more thing about the event-level zone is worth stating plainly, because it is the difference between a fix that lasts and a fix that has to be redone. A zone set on an event is stored on that event. Changing the primary zone afterwards, changing it back, or changing it again in six months leaves that event where it was put. A zone set only by changing the view is not stored anywhere and survives nothing. So the work of pinning the appointments that are tied to a place is done once, and the primary setting can then be treated as what it is, a preference about how the grid is drawn.

Guests, daylight saving, and the limits of any setting

Two things sit outside the reach of every setting described above.

The first is other people. Because each guest sees the event in their own zone, moving an event so that the number on your grid stays the same necessarily moves the number on theirs. There is no version of this where both sides keep their original clock reading. A recurring meeting with attendees in several countries has to pick which side stays fixed, and saying so in the event description costs one line and saves a quarterly argument.

The second is daylight saving. Google's documentation is candid about the edges here: events in past or future years might not reflect daylight saving changes and can be displayed incorrectly, with the displayed time adjusting automatically as the date approaches. It also notes that when a region changes its time zone rules, events created before Google knew about the change may sit in the wrong zone.

The practical consequence is narrow but real. A weekly meeting set up in March and running past the autumn changeover can be an hour out for one of the two parties for part of the year, because the two regions do not change on the same date. Meetings that matter across a changeover deserve one manual check rather than trust.

The order to do it in before travelling

Do the auditing before the setting is changed, not after, because afterwards every event on the screen has a misleading number on it.

Start by listing the timed events in the next few weeks that are anchored to a place: the appointments at a physical address, the meetings in the office you are leaving. Set the time zone on each of those events individually so they stay correct once the grid moves. Convert anything that is really a date, not an appointment, into an all-day event. Then change the primary zone, or answer the prompt when the calendar asks.

Finally, add the zone you left as a secondary display zone. Both readings are then visible side by side for the first week, which is the period when a misread hour actually costs something, and it can be switched off once the new zone feels normal.

Where the desktop side helps

Two things make this less painful outside the browser. Writing an event as a sentence and having the time read out of it is quicker than the dialog when a dozen local routines have to be recreated after a move, and that entry route is described under Entering events.

The other is what happens when a day has been redrawn into a new zone. Events that looked comfortably spaced can end up back to back, and an appointment with an address needs a trip in front of it. Working the travel out from the previous event and putting a block before it is covered under Travel time, and it is what turns a technically correct grid into a day that can actually be walked through. A comparison of the desktop calendars that do this on the Mac is worth a look before settling on one.

What to change first

Go through the next month and set the time zone on each event that is tied to a physical place, before touching the primary setting. Turn the date-shaped items into all-day events while you are there. Those two passes remove almost every wrong hour that a zone change produces.

Then change the primary zone once, deliberately, and keep the old zone visible as a secondary column for a week. Rebuilding the local routines afterwards is the part worth doing outside the browser, and Caltimate turns each of them into a single typed line on the Mac.