Module 3: Google Calendar

Reminders and Time Zones

Capsule description

This is the module's central capsule. Capsules 03-05 taught you the operations (create, read, update, delete). This capsule teaches you what makes those operations land right: that the event is at the correct time and that it fires the correct notices.

The dominant topic is the time zone. It is, without exaggeration, the #1 mistake in Calendar automations. You set "10:00" and the customer sees it at 16:00. Or worse: you see it fine, but the customer in another country sees it wrong. When a badly-zoned event reaches a real person, the damage is concrete: a missed call, a meeting no one shows up to.

The second half covers reminders (the notices before the event) and a glance at recurring events. By the end, your events will land at the right time for everyone, with the notices they need.

What you'll learn

By the end of this capsule you'll be able to:

✅ Understand why an event "shifts its time" and how to avoid it
✅ Set the time zone correctly when creating events
✅ Handle the multi-zone case (customer and you in different zones)
✅ Set up reminders (notices before the event)
✅ Understand recurring events and when to use them
✅ Diagnose schedule problems before they reach a customer

Why an event "shifts its time"

Remember from G2-M01 (the Schedule Trigger capsule): a time means nothing without its time zone. "10:00" is ambiguous — 10:00 where?

With Calendar, that ambiguity has three failure points:

The n8n server's zone. If your n8n runs on a server that's in UTC and you don't specify a zone, "10:00" is interpreted as 10:00 UTC.
The node's / the event's zone. The Calendar node has a Timezone field. If you don't set it, it inherits something that might not be what you want.
The zone of whoever looks at the event. Google Calendar shows the event to each person in their zone. If the event was saved wrong, everyone sees it wrong — each in their own way.

The correct model: an event is saved with an absolute instant + a reference time zone. "May 20, 10:00, America/Mexico_City". That's unambiguous: Google knows exactly which instant it is, and shows it correctly to someone in CDMX (10:00), in Bogotá (11:00), or in Madrid (18:00). The problem appears when you save "10:00" without the zone — Google has to guess, and it guesses wrong.

The solution: specify the zone, always

The rule is simple and you apply it on every Calendar node:

Set the node's Timezone field explicitly. Never leave it "by default".

Time zones for LATAM and Spain

The same ones as G2-M01 — worth having on hand:

Region	Timezone
Mexico (CDMX, Guadalajara)	`America/Mexico_City`
Colombia (Bogotá)	`America/Bogota`
Argentina (Buenos Aires)	`America/Argentina/Buenos_Aires`
Chile (Santiago)	`America/Santiago`
Peru (Lima)	`America/Lima`
Brazil (São Paulo)	`America/Sao_Paulo`
Spain (Madrid)	`Europe/Madrid`

How it's applied

On the Google Calendar node (Create or Update), find the Timezone field and choose your business's. And when building the dates with expressions, be consistent:

Start: {{ $now.setZone('America/Mexico_City').plus({ days: 1 }).set({ hour: 10 }).toISO() }}

setZone('America/Mexico_City') anchors the calculation in that zone. That way "10:00" means 10:00 in CDMX, no matter where n8n runs.

The multi-zone case: customer in another zone

The scenario that really bites: your business is in CDMX, but your customer is in Bogotá. You schedule "a call at 10:00". Whose 10:00?

There are two valid approaches, and you have to choose consciously:

Approach	How	When
Business time	You always schedule in your zone (`America/Mexico_City`). The customer sees the conversion on their calendar.	Your team coordinates many appointments; it's simpler to have everything in one zone
Customer time	You schedule in the customer's zone (which comes in as data).	The customer chose "10:00 my time" on a form

The important thing: the event is always saved with an explicit zone. If you save it right, Google does the conversion for you — the customer in Bogotá sees the correct time for Bogotá automatically. The mistake isn't "not converting"; the mistake is saving without a zone and letting Google guess.

Practical recommendation: for most businesses, schedule in the business's zone and let Google show the customer the conversion. It's the simplest and least error-prone. Only schedule "in customer time" if you have reliable data about their zone.

Reminders: the notices before the event

A reminder is the notice that pops up before the event happens ("your meeting is in 10 minutes"). When creating or updating an event, you can set them.

Reminder types

Type	How it notifies
Popup	Notification on the device (phone, browser)
Email	A reminder email

Setting them up in the node

In the Calendar node's options (Create/Update), there's a Reminders section. You can:

Use the calendar's defaults (the ones the person already set)
Define custom ones: type (popup/email) + how many minutes before

Typical business examples:

A sales call: popup 10 minutes before
An important delivery: email 1 day before + popup 1 hour before
A customer appointment: email 24h before (so they confirm) + popup 30 min before

Who gets the reminder. The reminders you set apply to the guests according to each one's settings. You can't "force" a reminder on someone else's phone if that person turned them off. Reminders are a strong suggestion, not a guarantee. For critical notices, combine the Calendar reminder with an explicit email from your workflow (Module 2).

Recurring events (a glance)

A recurring event repeats: "every Monday at 9:00", "the first day of each month". Calendar handles them with a recurrence rule (in RRULE format — the calendar standard).

For this module, what you need to know:

Creating a recurring one is possible from the node, passing a recurrence rule. The RRULE syntax is the same one you'd see in any calendar app.
When reading recurring ones (Get Many, capsule 04): the Single Events option decides whether the recurring event comes as a single entry (the rule) or "expanded" into each individual repetition. If you need the concrete occurrences, turn on Single Events.
Careful when updating/deleting: changing a recurring event can affect the whole series or a single occurrence — very different behaviors. In automation, recurring events are one of the most delicate topics.

Recommendation: for most business automations, don't create recurring events from the workflow. It's more predictable for your workflow to create individual events (one per appointment, one per delivery) than to handle the complexity of recurring series. Leave recurrence for events that really are a fixed series, and create those by hand. This is a design decision, not a technical limitation.

Common traps

Trap 1: Not setting the time zone

What happens: You leave the Timezone "by default". The event lands in the n8n server's zone (often UTC) and everyone sees it shifted.

How to avoid it: Set the Timezone field explicitly on every Calendar node. Always.

Trap 2: Testing only in your own zone

What happens: Everything looks fine because you're in the same zone as the server or the event. The customer in another zone sees it wrong and you never noticed.

How to avoid it: After creating an event, verify the time thinking about where the recipient is, not just where you are.

Trap 3: Building dates without anchoring the zone

What happens: You use {{ $now.plus({ days: 1 }).set({ hour: 10 }) }} without setZone. The "10" is interpreted in n8n's zone.

How to avoid it: Anchor with .setZone('your-zone') before setting the hour. And also set the node's Timezone field — the two must match.

Trap 4: Trusting that the reminder "always arrives"

What happens: You set a reminder and assume the customer will surely see it. The customer has reminders turned off.

How to avoid it: Calendar reminders are a suggestion, not a guarantee. For critical notices, add an email from your workflow.

Trap 5: Creating recurring events without understanding the scope of the changes

What happens: Your workflow updates a recurring event and, unintentionally, changes all 52 occurrences of the year.

How to avoid it: For automations, prefer individual events. If you work with recurring ones, understand very well the difference between "this occurrence" and "the whole series".

Exercise: the two-zones test

Goal: see with your own eyes how the time zone changes (or doesn't) an event's time.

Your task

Event without an explicit zone: create an event "Test zone A" for tomorrow at 14:00, without touching the Timezone field. Open it in calendar.google.com and note what time it shows.
Event with your zone: create "Test zone B" for tomorrow at 14:00, setting the Timezone field to your real zone (e.g. America/Mexico_City). Note what time it shows.
Compare: did they land at the same time? If not, you just saw Calendar's #1 bug in action.
With a reminder: create "Test zone C" with your correct zone and a popup reminder 15 minutes before. Verify on the event that the reminder was set.

See what you should observe

If your n8n runs on a server in UTC and your zone is CDMX (UTC-6), "Test zone A" probably shows up 6 hours shifted.
"Test zone B" should show up exactly at 14:00 — because you told it the zone.
The lesson: the Timezone field is not optional. The difference between A and B is the difference between a customer who makes their appointment and one who doesn't.

Summary and next step

The time zone is the #1 mistake in Calendar automations — "10:00" means nothing without its zone
An event must be saved with an instant + explicit zone; saving it "without a zone" makes Google guess, and it guesses wrong
Rule: set the node's Timezone field explicitly, always; anchor the dates with .setZone()
Multi-zone: choose consciously between "business time" (recommended, simpler) and "customer time" — but always save with an explicit zone
Reminders (popup/email) notify before the event — they're a strong suggestion, not a guarantee; for critical things, add an email from the workflow
Recurring events: for automations, prefer individual events — recurrence is delicate when updating/deleting
5 traps: not setting the zone, testing only in your zone, dates without anchoring, blindly trusting reminders, recurring events without understanding the scope

Before moving on you should be able to:

Explain why an event "shifts its time"
Set the time zone correctly on a Calendar node
Set up a reminder
Justify why to avoid recurring events in automations

What's next (capsule 07):

You now know how to create events at the right time. Capsule 07 covers the rest of what breaks in production: permission errors, invitations that don't arrive, date formats the API rejects, and limits. The Calendar troubleshooting manual.

Additional resources

IANA Timezones - Complete list of time zones.
n8n Google Calendar node Docs - Timezone, Reminders, and recurrence fields.
RRULE (recurrence rule) - The recurring-events standard, if you need to create them.

Created: May 14, 2026 Version: 1.0

← PreviousUpdating and Deleting Events Next →Google Calendar Troubleshooting