Módulo 5: Scheduling y Tiempo

Gestión de zonas horarias

Descripción de la cápsula

Timezones es el detalle que más errores causa en producción cuando trabajas con scheduling. Configuras "9am" sin pensarlo, y descubres que tu Schedule corre a las 3am hora local porque n8n usa UTC por default. O peor: workflow funciona correctamente en invierno y se descalibra cuando cambia a daylight saving.

Esta cápsula te enseña los fundamentos de timezones, cómo configurarlas en n8n correctamente, los timezones LATAM y España más comunes, y los edge cases que importan en producción.

Lo que vas a aprender

✅ Entender UTC, IANA timezones, y por qué importan
✅ Configurar timezone en Schedule Trigger y nodos Set
✅ Conocer timezones LATAM y España (cheatsheet)
✅ Manejar daylight saving (DST) sin sorpresas
✅ Trabajar con multiple timezones en un solo workflow

Conceptos clave

UTC

Coordinated Universal Time. El "estándar global" — la misma hora en todo el mundo. Es la referencia interna que usan servidores y APIs.

UTC nunca cambia (no tiene DST)
Cuando ves un timestamp 2026-05-11T14:30:00Z, la Z significa UTC

Offset

La diferencia con UTC. Ejemplo:

CDMX: UTC-6 (invierno) / UTC-5 (verano DST)
Madrid: UTC+1 (invierno) / UTC+2 (verano DST)
Buenos Aires: UTC-3 (no usa DST)

IANA Timezones

Nombres "humanos" para timezones: America/Mexico_City, Europe/Madrid. Son mejores que offsets fijos porque:

Manejan DST automáticamente
Sobreviven cambios políticos (Brasil eliminó DST en 2019 — IANA lo refleja)

Siempre usar IANA names, no offsets fijos.

Timezones de LATAM y España

Región	IANA Name	UTC offset (sin DST)	DST?
México (CDMX, Guadalajara)	`America/Mexico_City`	-6	Sí (mayormente)
Argentina (Buenos Aires)	`America/Argentina/Buenos_Aires`	-3	No
Chile (Santiago)	`America/Santiago`	-4	Sí
Colombia (Bogotá)	`America/Bogota`	-5	No
Perú (Lima)	`America/Lima`	-5	No
Ecuador (Quito)	`America/Guayaquil`	-5	No
Venezuela (Caracas)	`America/Caracas`	-4	No
Brasil (São Paulo)	`America/Sao_Paulo`	-3	No (desde 2019)
Uruguay (Montevideo)	`America/Montevideo`	-3	No
Paraguay (Asunción)	`America/Asuncion`	-4	Sí (cambió 2024)
Bolivia (La Paz)	`America/La_Paz`	-4	No
Costa Rica	`America/Costa_Rica`	-6	No
Panamá	`America/Panama`	-5	No
España (Madrid)	`Europe/Madrid`	+1	Sí

Nota: verifica timezones específicas según ciudad — algunos países tienen múltiples (México tiene 3, Argentina tiene 5, etc.).

Configurar timezone en Schedule Trigger

En el editor del Schedule:

Configurar cron expression
Buscar campo Timezone (en Options o en el panel principal según versión)
Elegir de la lista IANA

Sin timezone configurada

Si dejas blank, n8n usa la timezone del server — puede ser UTC, puede ser otra. Impredecible. Siempre configurar explícitamente.

Configurar timezone en expressions (Luxon)

Cuando usas Luxon en Set node:

{{ DateTime.now() }}                                      // UTC por default
{{ DateTime.now().setZone('America/Mexico_City') }}       // CDMX
{{ DateTime.now().setZone('Europe/Madrid') }}             // Madrid
{{ DateTime.fromISO($json.date).setZone('America/Bogota') }}  // Parse + convertir

.setZone() ajusta la representación para mostrar/calcular en esa timezone.

Caso típico: workflow para multi-timezone

Si tu negocio opera en varios países y quieres "9am hora local de cada cliente":

Opción 1: Múltiples workflows

Uno por timezone:

[Schedule 9am CDMX]: cron 0 9 * * *, timezone America/Mexico_City
[Schedule 9am Madrid]: cron 0 9 * * *, timezone Europe/Madrid
...

Opción 2: Un workflow con lógica por cliente

[Schedule cada hora UTC]
   │
[Sheets: leer clientes con su timezone]
   │
[Filter: ¿es 9am en su timezone?]
   │
[procesamiento]

Cada cliente tiene su timezone configurada. Filtro pasa solo los que están en su 9am ahora.

Trampas comunes con timezones

Trampa 1: Schedule sin timezone configurada

Qué pasa: Configuras "9am" sin timezone. Server n8n está en UTC. Schedule corre a las 9am UTC = 3am hora CDMX.

Cómo evitar: siempre configurar timezone explícitamente en Schedule.

Trampa 2: Mezclar offset y nombre IANA

Qué pasa: Configuras UTC-6 pensando CDMX. En verano CDMX es UTC-5 (DST). Tu workflow se desfasa 1 hora durante medio año.

Cómo evitar: Usar IANA names (America/Mexico_City), no offsets fijos.

Trampa 3: $now en distintas timezones inconsistente

Qué pasa: Workflow usa $now (UTC) en un Set, después DateTime.now().setZone(...) en otro. Los timestamps no coinciden.

Cómo evitar: Consistencia. Si trabajas con timezone X, todas las operaciones de fecha deben referir a X.

Trampa 4: API que devuelve timestamps en su propia timezone

Qué pasa: API te devuelve created_at: "2026-05-11 14:30:00" sin timezone. ¿Es UTC? ¿Es local de la API? Confusión.

Cómo evitar:

Verificar documentación del API sobre timezone de timestamps
Si no es claro, preguntar al provider
Asumir UTC es generalmente seguro pero no garantizado

Trampa 5: Olvidar DST

Qué pasa: Workflow funciona perfecto octubre-marzo. Llega abril (DST) y cambia 1 hora — workflow corre a las 8am o 10am en lugar de 9am.

Cómo evitar:

Usar IANA names (manejan DST automáticamente)
Después de DST, verificar manualmente que workflows críticos siguen funcionando

Cheat code: comparar timezones rápidamente

Para entender la relación entre timezones (sobre todo si tienes clientes/colaboradores en varias):

timeanddate.com/worldclock/meeting.html o savvytime.com

Te muestra: "Cuando son 9am en CDMX, son __ en Buenos Aires y __ en Madrid".

Ejercicio: timezone awareness

Caso: trabajas con clientes en CDMX, Buenos Aires, y Madrid. Quieres:

Workflow que manda reporte diario a cada equipo en su 9am local
Reporte interno (a ti) cuando todos los equipos están "activos"

Solución sugerida

Workflow 1: reporte por equipo

3 workflows (o 1 con múltiples Schedules y filter):
- Cron 0 9 * * 1-5, TZ America/Mexico_City → equipo CDMX
- Cron 0 9 * * 1-5, TZ America/Argentina/Buenos_Aires → equipo BA
- Cron 0 9 * * 1-5, TZ Europe/Madrid → equipo Madrid

Workflow 2: cuándo todos activos

Madrid 9am-6pm = UTC 8-17 (invierno) o 7-16 (verano)
BA 9am-6pm = UTC 12-21
CDMX 9am-6pm = UTC 15-24
Intersección: UTC 15-16 = todos activos solo 1-2 horas/día
Schedule en UTC 15-16 con filter de día hábil

Resumen

UTC es la referencia global, sin DST
IANA names son la forma correcta de configurar timezones
Siempre configurar timezone explícitamente en Schedules
LATAM y España tienen ~12 timezones distintas — usar el correcto
DST se maneja automáticamente con IANA names — pero verificar workflows críticos después de cambios
5 trampas: sin timezone, offset en lugar de IANA, inconsistencia, API sin timezone clara, olvidar DST

Lo que sigue: Cálculos con fechas en n8n — Luxon DateTime a fondo.

Creado: Mayo 11, 2026 Versión: 1.0

← AnteriorCron Expressions Avanzadas Siguiente →Cálculos con Fechas en n8n (Luxon DateTime)