Módulo 3: Google Calendar
Recordatorios y Zonas Horarias
Descripción de la cápsula
Esta es la cápsula central del módulo. Las cápsulas 03-05 te enseñaron las operaciones (crear, leer, actualizar, eliminar). Esta cápsula te enseña lo que hace que esas operaciones queden bien: que el evento esté a la hora correcta y que dispare los avisos correctos.
El tema dominante es la zona horaria. Es, sin exagerar, el error #1 de las automatizaciones de Calendar. Pones "10:00" y el cliente lo ve a las 16:00. O peor: lo ves bien tú, pero el cliente en otro país lo ve mal. Cuando un evento mal-zonificado le llega a una persona real, el daño es concreto: una llamada perdida, una reunión a la que nadie llega.
La segunda mitad cubre los recordatorios (los avisos antes del evento) y un vistazo a los eventos recurrentes. Al terminar, tus eventos quedarán a la hora correcta para todos, con los avisos que necesitan.
Lo que vas a aprender
Al terminar esta cápsula serás capaz de:
- ✅ Entender por qué un evento "se mueve de hora" y cómo evitarlo
- ✅ Configurar la zona horaria correctamente al crear eventos
- ✅ Manejar el caso multi-zona (cliente y tú en zonas distintas)
- ✅ Configurar recordatorios (avisos antes del evento)
- ✅ Entender los eventos recurrentes y cuándo usarlos
- ✅ Diagnosticar problemas de horario antes de que lleguen a un cliente
Por qué un evento "se mueve de hora"
Recuerda de G2-M01 (cápsula de Schedule Trigger): una hora no significa nada sin su zona horaria. "Las 10:00" es ambiguo — ¿10:00 de dónde?
Con Calendar, esa ambigüedad tiene tres puntos de fallo:
- La zona del servidor de n8n. Si tu n8n corre en un servidor que está en UTC y no especificas zona, "10:00" se interpreta como 10:00 UTC.
- La zona del nodo / el evento. El nodo de Calendar tiene un campo Timezone. Si no lo configuras, hereda algo que quizás no es lo que quieres.
- La zona del que mira el evento. Google Calendar le muestra el evento a cada persona en su zona. Si el evento se guardó mal, todos lo ven mal — cada uno a su manera.
El modelo correcto: un evento se guarda con un instante absoluto + una zona horaria de referencia. "20 de mayo, 10:00,
America/Mexico_City". Eso es inequívoco: Google sabe exactamente qué instante es, y se lo muestra correctamente a alguien en CDMX (10:00), en Bogotá (11:00) o en Madrid (18:00). El problema aparece cuando guardas "10:00" sin la zona — Google tiene que adivinar, y adivina mal.
La solución: especifica la zona, siempre
La regla es simple y la aplicas en cada nodo de Calendar:
Configura el campo Timezone del nodo explícitamente. Nunca lo dejes "por defecto".
Zonas horarias de LATAM y España
Las mismas de G2-M01 — vale tenerlas a mano:
| Región | Timezone |
|---|---|
| México (CDMX, Guadalajara) | America/Mexico_City |
| Colombia (Bogotá) | America/Bogota |
| Argentina (Buenos Aires) | America/Argentina/Buenos_Aires |
| Chile (Santiago) | America/Santiago |
| Perú (Lima) | America/Lima |
| Brasil (São Paulo) | America/Sao_Paulo |
| España (Madrid) | Europe/Madrid |
Cómo se aplica
En el nodo Google Calendar (Create o Update), busca el campo Timezone y elige el de tu negocio. Y al construir las fechas con expressions, sé consistente:
Start: {{ $now.setZone('America/Mexico_City').plus({ days: 1 }).set({ hour: 10 }).toISO() }}
setZone('America/Mexico_City') ancla el cálculo en esa zona. Así "las 10:00" significa 10:00 en CDMX, sin importar dónde corra n8n.
El caso multi-zona: cliente en otra zona
El escenario que de verdad muerde: tu negocio está en CDMX, pero tu cliente está en Bogotá. Agendas "una llamada a las 10:00". ¿10:00 de quién?
Hay dos enfoques válidos, y tienes que elegir conscientemente:
| Enfoque | Cómo | Cuándo |
|---|---|---|
| Hora del negocio | Siempre agendas en tu zona (America/Mexico_City). El cliente ve la conversión en su calendario. | Tu equipo coordina muchas citas; es más simple tener todo en una zona |
| Hora del cliente | Agendas en la zona del cliente (que viene como dato). | El cliente eligió "10:00 mi hora" en un formulario |
Lo importante: el evento siempre se guarda con una zona explícita. Si lo guardas bien, Google hace la conversión por ti — el cliente en Bogotá ve la hora correcta para Bogotá automáticamente. El error no es "no convertir"; el error es guardar sin zona y dejar que Google adivine.
Recomendación práctica: para la mayoría de negocios, agenda en la zona del negocio y deja que Google le muestre al cliente la conversión. Es lo más simple y lo menos propenso a error. Solo agenda "en hora del cliente" si tienes el dato confiable de su zona.
Recordatorios: los avisos antes del evento
Un recordatorio es el aviso que salta antes de que el evento ocurra ("tu reunión es en 10 minutos"). Al crear o actualizar un evento, puedes configurarlos.
Tipos de recordatorio
| Tipo | Cómo avisa |
|---|---|
| Popup | Notificación en el dispositivo (teléfono, navegador) |
| Un correo recordatorio |
Configurarlos en el nodo
En las opciones del nodo Calendar (Create/Update), hay una sección de Reminders. Puedes:
- Usar los predeterminados del calendario (los que la persona ya configuró)
- Definir personalizados: tipo (popup/email) + cuántos minutos antes
Ejemplos típicos de negocio:
- Una llamada de ventas: popup 10 minutos antes
- Una entrega importante: email 1 día antes + popup 1 hora antes
- Una cita con cliente: email 24h antes (para que confirme) + popup 30 min antes
Quién recibe el recordatorio. Los recordatorios que configuras aplican a los invitados según la configuración de cada uno. No puedes "forzar" un recordatorio en el teléfono de otra persona si esa persona los desactivó. Los recordatorios son una sugerencia fuerte, no una garantía. Para avisos críticos, combina el recordatorio de Calendar con un correo explícito de tu workflow (Módulo 2).
Eventos recurrentes (un vistazo)
Un evento recurrente se repite: "todos los lunes a las 9:00", "el primer día de cada mes". Calendar los maneja con una regla de recurrencia (en formato RRULE — el estándar de calendarios).
Para este módulo, lo que necesitas saber:
- Crear un recurrente es posible desde el nodo, pasando una regla de recurrencia. La sintaxis RRULE es la misma que verías en cualquier app de calendario.
- Al leer recurrentes (Get Many, cápsula 04): la opción Single Events decide si el evento recurrente viene como una sola entrada (la regla) o "expandido" en cada repetición individual. Si necesitas las ocurrencias concretas, activa Single Events.
- Cuidado al actualizar/eliminar: cambiar un evento recurrente puede afectar toda la serie o una sola ocurrencia — comportamientos muy distintos. En automatización, lo recurrente es de los temas más delicados.
Recomendación: para la mayoría de automatizaciones de negocio, no crees eventos recurrentes desde el workflow. Es más predecible que tu workflow cree eventos individuales (uno por cita, uno por entrega) que manejar la complejidad de las series recurrentes. Deja lo recurrente para eventos que de verdad son una serie fija, y créalos a mano. Esto es una decisión de diseño, no una limitación técnica.
Trampas comunes
Trampa 1: No configurar la zona horaria
Qué pasa: Dejas el Timezone "por defecto". El evento queda en la zona del servidor de n8n (a menudo UTC) y todos lo ven desplazado.
Cómo evitar: Configura el campo Timezone explícitamente en cada nodo de Calendar. Siempre.
Trampa 2: Probar solo en tu propia zona
Qué pasa: Todo se ve bien porque tú estás en la misma zona que el servidor o el evento. El cliente en otra zona lo ve mal y tú nunca lo notaste.
Cómo evitar: Después de crear un evento, verifica la hora pensando en dónde está el destinatario, no solo dónde estás tú.
Trampa 3: Construir fechas sin anclar la zona
Qué pasa: Usas {{ $now.plus({ days: 1 }).set({ hour: 10 }) }} sin setZone. El "10" se interpreta en la zona de n8n.
Cómo evitar: Ancla con .setZone('tu-zona') antes de fijar la hora. Y configura también el campo Timezone del nodo — los dos deben coincidir.
Trampa 4: Confiar en que el recordatorio "siempre llega"
Qué pasa: Configuras un recordatorio y asumes que el cliente seguro lo verá. El cliente tiene los recordatorios desactivados.
Cómo evitar: Los recordatorios de Calendar son una sugerencia, no una garantía. Para avisos críticos, suma un correo de tu workflow.
Trampa 5: Crear recurrentes sin entender el alcance de los cambios
Qué pasa: Tu workflow actualiza un evento recurrente y, sin querer, cambia las 52 ocurrencias del año.
Cómo evitar: Para automatizaciones, prefiere eventos individuales. Si trabajas con recurrentes, entiende muy bien la diferencia entre "esta ocurrencia" y "toda la serie".
Ejercicio: la prueba de las dos zonas
Objetivo: ver con tus propios ojos cómo la zona horaria cambia (o no) la hora de un evento.
Tu tarea
- Evento sin zona explícita: crea un evento "Prueba zona A" para mañana a las 14:00, sin tocar el campo Timezone. Ábrelo en calendar.google.com y anota a qué hora aparece.
- Evento con tu zona: crea "Prueba zona B" para mañana a las 14:00, configurando el campo Timezone con tu zona real (ej.
America/Mexico_City). Anota a qué hora aparece. - Compara: ¿quedaron a la misma hora? Si no, acabas de ver el bug #1 de Calendar en acción.
- Con recordatorio: crea "Prueba zona C" con tu zona correcta y un recordatorio popup 15 minutos antes. Verifica en el evento que el recordatorio quedó configurado.
Ver qué deberías observar
- Si tu n8n corre en un servidor en UTC y tu zona es CDMX (UTC-6), "Prueba zona A" probablemente aparece 6 horas desplazada.
- "Prueba zona B" debe aparecer exactamente a las 14:00 — porque le dijiste la zona.
- La lección: el campo Timezone no es opcional. La diferencia entre A y B es la diferencia entre un cliente que llega a su cita y uno que no.
Resumen y siguiente paso
- La zona horaria es el error #1 de las automatizaciones de Calendar — "10:00" no significa nada sin su zona
- Un evento debe guardarse con un instante + zona explícita; guardarlo "sin zona" hace que Google adivine, y adivina mal
- Regla: configura el campo Timezone del nodo explícitamente, siempre; ancla las fechas con
.setZone() - Multi-zona: elige conscientemente entre "hora del negocio" (recomendado, más simple) y "hora del cliente" — pero guarda siempre con zona explícita
- Recordatorios (popup/email) avisan antes del evento — son una sugerencia fuerte, no una garantía; para lo crítico, suma un correo del workflow
- Eventos recurrentes: para automatizaciones, prefiere eventos individuales — lo recurrente es delicado al actualizar/eliminar
- 5 trampas: no configurar zona, probar solo en tu zona, fechas sin anclar, confiar ciegamente en recordatorios, recurrentes sin entender el alcance
Antes de avanzar deberías poder:
- Explicar por qué un evento "se mueve de hora"
- Configurar la zona horaria correctamente en un nodo de Calendar
- Configurar un recordatorio
- Justificar por qué evitar eventos recurrentes en automatizaciones
Lo que sigue (cápsula 07):
Ya sabes crear eventos a la hora correcta. La cápsula 07 cubre el resto de lo que se rompe en producción: errores de permisos, invitaciones que no llegan, formatos de fecha que la API rechaza, y límites. El manual de troubleshooting de Calendar.
Recursos adicionales
- IANA Timezones - Lista completa de zonas horarias.
- n8n Google Calendar node Docs - Campos de Timezone, Reminders y recurrencia.
- RRULE (regla de recurrencia) - El estándar de eventos recurrentes, si necesitas crearlos.
Creado: Mayo 14, 2026 Versión: 1.0