Husos horarios y plataformas

La misma cadena cron puede disparar en instantes distintos según quién la interprete y en qué huso horario.

Crontab de usuario Linux

El crontab tradicional en un servidor suele evaluar expresiones en el huso horario local de la máquina (a menudo configurado vía /etc/timezone o timedatectl).

Si el servidor cambia de región o cambian reglas DST, los schedules de reloj de pared se desplazan salvo que estandarices UTC a nivel OS.

Kubernetes CronJob

La spec de CronJob usa cron estándar de cinco campos. Desde Kubernetes 1.25+, el campo timeZone permite nombrar una zona IANA (por ejemplo Asia/Shanghai) en lugar de heredar la hora local del plano de control.

Sin zona explícita, el comportamiento depende de la configuración del kube-controller-manager — no asumas la hora local de tu portátil.

GitHub Actions

El cron de on.schedule se interpreta siempre en UTC. No hay bandera de huso horario por workflow.

0 9 * * 1-5 en Actions significa 09:00 UTC en días laborables — no 09:00 en Shanghai o San Francisco. Convierte conscientemente al coordinar con horas de guardia local.

Quartz, AWS EventBridge y extensiones

Algunos sistemas usan seis campos (segundos primero) o marcadores ? para «sin valor específico». Copiar una línea Linux en Quartz sin traducir es un bug frecuente.

Lee la tabla gramatical de la plataforma antes de reutilizar una expresión entre proveedores.

Casos límite DST

Schedules como «02:30 cada día» pueden omitir o repetir una hora cuando empieza o termina el horario de verano en zonas locales. Schedules basados en UTC evitan esa clase de bug a costa de derivar respecto a horas laborables locales.

Vista previa en la zona correcta

Al validar, pregunta siempre:

1. ¿Qué motor ejecuta este job?
2. ¿Qué huso horario usa ese motor?
3. ¿Cuáles son las próximas tres horas de disparo en esa zona y en UTC?

Conclusión clave

Documenta huso horario + plataforma junto a cada línea cron en runbooks. «Cada día a las 9» no significa nada sin saber de qué reloj.