← Volver al blog devops

El cambio de hora y los timers de mi servidor: por qué todo corre en UTC

7 de septiembre de 2026 · Rodolfo Ulloa
El cambio de hora y los timers de mi servidor: por qué todo corre en UTC
devopsinfraestructurasystemddockerdebian

Cada vez que se acerca el cambio de hora en Chile veo la misma ola de comentarios: "¿dormimos una hora más o una hora menos?", "¿mi celular se va a actualizar solo?". Para mí, que administro un servidor casero con una docena de servicios corriendo en Docker sobre Debian 13, el cambio de hora no es una curiosidad de calendario — es el único momento del año en que realmente pongo a prueba si mis tareas programadas están bien diseñadas o si simplemente nunca las until ahora nunca fallaron por suerte.

El problema no es la hora, es la ambigüedad

Un timer de systemd o una entrada de cron que dice "ejecútate a las 02:00" parece inofensivo. El problema aparece quien te lo describa en hora local en una zona horaria con horario de verano: la noche del cambio, las 02:00 pueden no existir (el reloj salta de 01:59 a 03:00) o pueden existir dos veces (el reloj retrocede de 23:59 a 23:00 y vuelve a pasar por esa hora). Un scheduler que interpreta "02:00" en hora local puede saltarse la ejecución esa noche, o —peor— dispararla dos veces si el sistema no lo maneja con cuidado.

systemd es razonablemente inteligente con esto si usas OnCalendar y el sistema tiene timedatectl configurado correctamente, pero cron clásico depende del comportamiento del daemon y de cómo esté seteado TZ en el entorno. Y ahí es donde un servidor casero, armado a punta de prueba y error, tiene más superficie de la que uno cree: cada contenedor Docker puede traer su propia zona horaria, o ninguna, y eso no siempre coincide con la del host.

Lo que encontré al auditar mis propios timers

Hice el ejercicio simple de correr timedatectl status en el host y comparar contra docker inspect <contenedor> | grep -i tz en cada servicio. El resultado: el host estaba correctamente en America/Santiago con NTP sincronizado, pero un par de contenedores no tenían la variable TZ seteada en absoluto, así que por defecto corrían en UTC internamente mientras yo, mentalmente, seguía asumiendo hora de Chile cuando revisaba sus logs. No era un bug que rompiera nada — pero sí una fuente de confusión cada vez que comparaba timestamps entre el log de un contenedor y el del sistema anfitrión, especialmente la noche de un cambio de hora, cuando por una hora ambos relojes literalmente no coinciden con lo que dice la pantalla.

La decisión: todo interno en UTC, la conversión solo en la capa que la persona ve

Terminé aplicando una regla simple que ya es estándar en sistemas distribuidos más grandes, pero que en un servidor personal es fácil posponer "para después": todos los procesos, timers y contenedores corren y registran en UTC. La conversión a hora de Chile ocurre solo en el punto donde un humano realmente la necesita — el dashboard, el MOTD que se muestra al hacer login por SSH, o los timestamps que se muestran en la interfaz de algún servicio. Esto significa, por ejemplo, que las actualizaciones automáticas que casi reinician Home Assistant a medianoche están programadas contra un horario UTC fijo, no contra una "medianoche" que dos veces al año cambia de significado sin avisar.

La ventaja no es solo evitar el bug puntual del cambio de hora. Es que un timer en UTC es determinista todo el año: la ventana entre backups, entre chequeos de salud, entre reintentos, es exactamente la misma en marzo que en septiembre. Nada se corre el doble ni se salta por una hora que, en la línea de tiempo del sistema, técnicamente no existió esa noche.

Un detalle que casi se me pasa: el MOTD

El único lugar donde la hora local sí importa de verdad es la interfaz humana. El MOTD que se transformó en un dashboard vivo muestra el estado del túnel y los servicios en el momento en que alguien entra por SSH — y ahí sí quiero ver la hora de Santiago, no UTC, porque soy yo leyéndolo, no un scheduler. La regla no es "nunca uses hora local", es "no dejes que un proceso automatizado dependa de una hora local ambigua dos noches al año".

No es un cambio dramático ni algo que se note en el día a día. Pero es exactamente el tipo de decisión de diseño que separa una infraestructura que "funciona hasta que no" de una que sigue corriendo igual, cambie o no cambie la hora en el país.