Cómo configurar y gestionar la zona horaria en n8n

Última actualización: 26/10/2026

  • Configuración de la variable GENERIC_TIMEZONE para ajustar la hora global del sistema.
  • Uso de la librería Luxon y el nodo Date & Time para gestionar horarios específicos por flujo.
  • Implementación de timestamptz en PostgreSQL para garantizar la integridad de las fechas en UTC.
n8n

Por desgracia, esto pasa más a menudo de lo que crees: montas un flujo de trabajo impecable, pero de repente te das cuenta de que los correos salen a las tres de la mañana o que tus registros de base de datos parecen venir del futuro. Configurar y gestionar la zona horaria en n8n es esencial para evitar problemas, porque el manejo del tiempo en esta plataforma es el corazón de la ejecución.

La mayoría de las instalaciones vienen por defecto en UTC, lo cual es genial para los programadores pero un dolor de cabeza para quien necesita que un trigger de cron se active exactamente a las 9:00 AM de Madrid o Bogotá. Para que no te vuelvas loco con los desfases horarios, vamos a ver cómo dominar la configuración temporal desde el servidor hasta los detalles más finos de SQL.

Ajustes globales para instalaciones propias (Self-Hosted)

Si tienes n8n corriendo en tu propio servidor, ya sea mediante Docker o npm, lo más robusto es atacar el problema desde las variables de entorno. De esta forma, el núcleo de la herramienta reconoce la hora nativa sin dar saltos extraños.

La variable estrella aquí es GENERIC_TIMEZONE. Si utilizas Docker Compose, debes entrar en tu archivo docker-compose.yml y, dentro de la sección de environment, añadir la zona horaria siguiendo el estándar IANA. Por ejemplo, para España usarías Europe/Madrid. Un truco de experto cuando se trata de ajustar la zona horaria en n8n es añadir también la variable TZ=Europe/Madrid, ya que mientras la primera es para la lógica de n8n, la segunda ajusta el reloj del propio sistema operativo del contenedor.

Contenido exclusivo - Clic Aquí  Cómo clasificar documentos en Paperless-ngx automáticamente

Si prefieres el camino de npm, simplemente debes exportar la variable antes de lanzar el servicio ejecutando en tu terminal export GENERIC_TIMEZONE=\"America/New_York\" && n8n start. No olvides que si haces cambios en Docker, no basta con reiniciar; debes ejecutar docker-compose up -d para que las variables se refresquen de verdad.

Cómo configurar y gestionar la zona horaria en n8n
Cómo configurar y gestionar la zona horaria en n8n

Gestión en n8n Cloud y flujos específicos

Para quienes usan la versión en la nube o la de escritorio, la manera de gestionar la zona horaria en n8n es más visual. Generalmente, el sistema intenta leer la hora de tu navegador, pero es vital revisar los ajustes regionales en el Workspace para asegurar que la cuenta global esté alineada con tu operativa diaria.

Ahora bien, hay casos donde no quieres cambiar la hora de todo el servidor porque tienes clientes en distintos países. Aquí es donde entra la magia de Luxon, la librería interna de n8n. Mediante expresiones, puedes forzar una zona horaria solo para un dato concreto usando {{ $now.setZone('America/Mexico_City').toString() }}, lo que te permite moverte entre continentes sin romper el resto de tus flujos.

Contenido exclusivo - Clic Aquí  Guía Completa para Rellenar Formularios con Inteligencia Artificial y Browser Use

Si no te apetece pelearte con el código, el nodo Date & Time es tu mejor aliado. Con él puedes formatear fechas, sumar o restar horas y, sobre todo, realizar conversiones explícitas entre una zona de origen y una de destino sin escribir una sola línea de JavaScript.

El reto de las bases de datos y PostgreSQL

Es muy común que al mirar una base de datos veas fechas raras con un +00 al final. Esto no es un error, es el formato UTC. El problema surge cuando guardas una hora local pensando que el sistema la entiende. Por ejemplo, si guardas las 9 AM de Monterrey como +00, en realidad estás diciendo que son las 9 AM de Londres, lo que crea un desfase de varias horas en tus reportes.

La solución profesional es utilizar el tipo de dato timestamptz (timestamp with time zone). Esto permite que PostgreSQL guarde todo en UTC pero lo convierta a tu hora local al consultarlo. En lugar de hacer cálculos manuales, puedes usar la sentencia AT TIME ZONE 'America/Monterrey' en tus queries de SQL para que la base de datos haga el trabajo sucio por ti.

Comparado con las Data Tables internas de n8n, usar SQL es otro nivel. Mientras que en una tabla simple necesitarías una cadena de 8 nodos (filtros, código para convertir fechas, ifs) para sacar un informe diario, con una consulta SQL bien optimizada puedes hacer todo eso en un único nodo, mejorando drásticamente el rendimiento y la facilidad de mantenimiento.

Contenido exclusivo - Clic Aquí  Guía Completa de Activepieces: Automatización Inteligente y Agentes de IA
Cómo configurar y gestionar la zona horaria en n8n
Cómo configurar y gestionar la zona horaria en n8n

Consejos prácticos y errores habituales

Para evitar que tus automatizaciones se vuelvan locas, evita a toda costa usar offsets fijos como \»GMT+1\». Es mucho mejor usar los nombres de la base de datos IANA porque gestionan automáticamente el horario de verano y de invierno. Si usas un offset manual, te tocará cambiarlo dos veces al año a mano.

Otro error típico es comparar fechas directamente en SQL sin convertir la zona horaria. Siempre que busques registros de \»hoy\», asegúrate de envolver la columna de fecha con la conversión a tu zona local antes de compararla con la fecha actual. Además, intenta estandarizar siempre el envío de datos en formato ISO 8601, que es el lenguaje universal que evita confusiones entre el formato día/mes y mes/día.

Implementar n8n para automatizar tareas de oficina, como informes de llamadas o notificaciones de Telegram, requiere una base sólida en la gestión del tiempo. Ya sea configurando las variables de entorno en Docker, aprovechando la potencia de Luxon en los nodos o delegando la lógica temporal a PostgreSQL mediante SQL, el objetivo es eliminar el error humano. Al centralizar la hora en UTC y convertirla solo en la salida, logras un sistema escalable y profesional que funciona con precisión de reloj suizo sin importar dónde esté el servidor.