Can more than two time zones be shown on the Google Calendar grid?

Google documents a primary time zone plus a secondary and a tertiary one, so three hour columns on the grid is the ceiling. For a fourth region and beyond, the world clock setting shows current local times for other parts of the world, though it reports the time now rather than aligning to the blocks on the grid.

Does changing the primary time zone move existing events?

No. Events are stored with a time and a zone, so changing the account time zone changes how they are displayed, not when they happen. A ten o'clock meeting in Tokyo shown from London will read as a different hour and still be the same meeting.

Why does a weekly call shift by an hour a few times a year?

A recurring event is expanded in one specific time zone, and the Calendar API requires that zone to be set on the series. The series keeps its local hour in that zone, so every other country sees it move when either side changes its clocks, and the change dates differ by country.

Should a time zone be set on individual events?

Set it when the event is defined by a place rather than by the participants, such as a flight, a market open or a broadcast. For ordinary meetings among people in the same region the account time zone is enough, and adding a per event zone makes the grid harder to read for no gain.

What happens to an event scheduled in the hour that daylight saving skips?

The iCalendar standard specifies that a local time which does not occur is read using the offset from before the gap, which moves it an hour later in practice. Calendars follow that rule rather than refusing the event, so the block exists but sits an hour away from where it was typed.

Add a time zone to Google Calendar and see both sides of the day

Someone in another country proposes a call, and the arithmetic starts. Add nine hours, subtract one for the season, check whether that country moved its clocks last weekend. The point of adding a time zone to Google Calendar is to stop doing that arithmetic, and there are four separate places a time zone can live in a calendar. Picking the wrong one is why a second time zone often gets added and still does not help.

The account holds one time zone and can display two more

Google Calendar stores exactly one time zone for the account. The Calendar API exposes user settings as a list, and the time zone appears there as a single entry named timezone, described as the ID of the user's time zone, taking a value from the IANA time zone database. There is no list and no second slot. Everything on the grid is drawn against that one value, which is why moving country and not changing it makes every event look an hour or nine hours wrong at once.

On top of that single stored value, the calendar can draw extra rulers. Google's help for using Calendar in different time zones is explicit about how many: in addition to the primary time zone, a secondary and a tertiary time zone can be added, and the additional time zones appear on the left of the calendar grid. It is a display setting and it lives next to the primary one, in the time zone section of the calendar settings. Every event then sits against two or three columns of hours instead of one.

The secondary time zone changes nothing about the data. Events keep the times they had. No event moves, nothing is rewritten, and turning the second ruler off returns the grid to exactly what it was. That makes it the safest of the four options to try, and the one to try first.

One caveat is worth stating. Three columns is the documented ceiling, and each one costs width on the left edge of the grid. Anyone coordinating four or more regions will fill the two extra slots with the regions they deal with most and keep doing arithmetic for the rest, which is the point at which the world clock becomes the better tool.

The world clock and the second ruler solve different problems

The world clock is a separate setting, described in Google's own list of Calendar settings as showing the time from other parts of the world on the calendar. It answers the question of what time it is right now in each place. It scales past three zones, because it is a list rather than a column on the grid.

The extra rulers answer a different question, which is what time a specific block on the grid is for someone else. They are anchored to the events, not to now. Reading them requires no thought, because the block and the hour sit on the same line.

The distinction matters when choosing what to turn on. Deciding whether it is reasonable to send a message right now is a world clock question. Deciding whether an eleven o'clock slot is cruel to the other side is a second ruler question. Most people who complain that adding a time zone did not help had a scheduling problem and turned on the clock list.

Where the time zone lives	What it changes	How many
Account setting	Every event's displayed time	One
Secondary and tertiary display	Adds one or two more hour columns to the grid	Two
World clock panel	Shows current local time in a list	Several
A single event	The zone that event's time is anchored to	One per event

Turning on the extra rulers

Both settings sit in the same place, in the calendar settings under the section for time zone. The primary time zone is a searchable list of cities and countries, the extra rulers are switched on by a box worded as showing additional time zones, and the secondary and then the tertiary zone are chosen underneath it. The world clock is its own setting. Nothing here is destructive, and none of it asks the calendar to resync.

A time zone set on the event itself

The fourth place is the event. A single event can carry its own time zone, independent of the account, and this is the option that actually moves data rather than display. The Calendar API documents it on both the start and end of an event as a timeZone field formatted as an IANA time zone database name, giving Europe/Zurich as its example.

For a one-off event the field is optional, and the documentation describes it as indicating a custom time zone for the event start and end. Setting it is useful when an event is defined by somewhere else's clock. A flight departure, a market open, a broadcast: these happen at a local time in a place, and anchoring them to that place means they stay correct when the traveller moves or when either country shifts its clocks.

For a recurring event the same field stops being optional. The API states that for recurring events the field is required, and that it specifies the time zone in which the recurrence is expanded. This is the single most consequential sentence in the whole topic. A weekly call is not a list of times. It is a rule, and the rule is unrolled against one time zone. Whoever creates the series decides whose clock the series follows, and everyone else inherits the consequences.

Anything that turns typed or spoken text into an event has to resolve this too, because a phrase like next Tuesday at nine has no meaning without a zone. The Entering events section of the guide covers how a parsed phrase gets anchored, which is worth reading before trusting quick entry with cross border meetings.

What happens on the two weekends the clocks move

This is where a calendar that looked fine for months produces a meeting nobody attends. The behaviour is specified, not arbitrary, and the iCalendar standard that every one of these systems exchanges events in states it directly.

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 as well. When the local time described does not occur, which is the hour that is skipped going into daylight time, the value is read using the offset from before the gap. The worked example in the standard is that a 2:30 in the morning value on the New York transition date resolves to 3:30 in the morning, one hour later than the reading before the gap.

The practical effect on a recurring meeting is this. A series anchored to one country keeps its local hour in that country and moves by an hour in every other country, twice a year, on dates that differ by country. Europe and the United States change on different weekends, so there are stretches of a few weeks each year where the usual gap between them is off by an hour. Japan, which does not observe daylight saving, absorbs every one of those shifts from the other side.

None of this is a bug to be fixed. It is a decision to be made explicitly: whose local hour is the series defined by. Making that choice once, at creation, prevents the annual rediscovery.

The case for anchoring to the smaller side

When a meeting has one participant in a zone without daylight saving and one in a zone with it, anchoring the series to the zone that changes keeps that person's hour stable and moves the other. Anchoring to the zone that does not change does the reverse. Neither is correct in general. What is worth avoiding is leaving the decision to whoever happened to create the invitation.

Guests see the meeting in their own zone, not yours

A worry that stops people adding a time zone is the fear of sending an invitation at the wrong hour. It is misplaced. An event is stored as an instant plus a zone, and every guest's calendar renders that instant against their own account time zone. A block created at ten in the morning in Tokyo appears at the correct local hour for a guest in Berlin without anyone converting anything.

That is also why writing a time zone into the event title is a habit worth dropping. A title reading "10:00 JST sync" will be drawn at the guest's local hour with a contradictory label attached to it, and the label is the part people read. The same applies to putting a converted time in the description. Both age badly the moment either side changes its clocks, because the stored instant updates and the typed text does not.

The one thing that genuinely needs stating in words is which side the series follows. A line in the description saying the series is anchored to the organizer's local hour costs nothing and answers the question that comes up every spring and autumn.

There is a related case worth knowing about. When an invitation arrives from a system outside Google, the event carries its own time zone definition rather than relying on a shared database. The iCalendar standard defines a whole component for this, requiring an identifier and at least one rule describing standard or daylight behaviour, so the receiving calendar can reproduce the sender's local time exactly. That is why an invitation from an unfamiliar system sometimes renders at an hour that does not match any zone the account has configured. The event is being read against a definition it brought with it, which is the standard working as designed rather than a fault.

Reading a two zone grid without arithmetic

Once the extra rulers are on, a habit makes them useful. Read the far column first when proposing a slot, rather than converting after the fact. A block that looks like a pleasant two o'clock becomes an obvious refusal at four in the morning on the other side, and it takes no calculation to see it.

The extra columns also make a category of error visible that is otherwise invisible: events whose own time zone differs from the account. These render at a position that does not match the typed hour, which looks wrong until the event's own zone is checked. A calendar that shows the event's zone in the detail panel rather than hiding it saves the confusion.

Desktop calendars for the Mac differ in how much of this they surface at a glance, from showing a second hour column to showing each event's own zone inline. The Compared with other calendars page lays out where the Mac options land on that, which is the relevant question for anyone whose week spans regions rather than cities.

What to change first

Turn on the additional time zones for the one or two regions dealt with most, because it costs nothing and changes no data. Then open the one or two recurring cross border meetings that matter and check which time zone the series is expanded in, since that is the field that produces the twice yearly drift. If the grid still needs reading twice, a Mac calendar built to show both sides of the day is the next step, and Caltimate is one of them.