Lição 3
Fusos horários e plataformas
Crontab local vs schedulers em UTC — Linux, Kubernetes e GitHub Actions.
A mesma string cron pode disparar em instantes diferentes conforme quem interpreta e em qual fuso.
Crontab de usuário no Linux
O crontab tradicional em servidor em geral avalia expressões no fuso local da máquina (muitas vezes via /etc/timezone ou timedatectl).
Se o servidor muda de região ou regras de horário de verão mudam, schedules de relógio de parede deslocam — a menos que você padronize UTC no nível do SO.
CronJob no Kubernetes
A spec de CronJob usa cron padrão de cinco campos. Desde Kubernetes 1.25+, o campo timeZone permite nomear uma zona IANA (por exemplo America/Sao_Paulo) em vez de herdar o horário local do control plane.
Sem zona explícita, o comportamento depende da configuração do kube-controller-manager — não assuma o horário local do seu laptop.
GitHub Actions
O cron em on.schedule é sempre interpretado em UTC. Não há flag de fuso por workflow.
0 9 * * 1-5 em Actions significa 09:00 UTC em dias úteis — não 09:00 em São Paulo ou San Francisco. Converta de propósito ao alinhar com plantão local.
Quartz, AWS EventBridge e extensões
Alguns sistemas usam seis campos (segundos primeiro) ou placeholders ? para “sem valor específico”. Colar uma linha Linux no Quartz sem tradução é bug frequente.
Leia a tabela de gramática da plataforma antes de reutilizar uma expressão entre fornecedores.
Casos de horário de verão
Schedules como “02:30 todo dia” podem pular ou repetir uma hora quando o horário de verão começa ou termina em fusos locais. Schedules em UTC evitam essa classe de bug, à custa de deslocar em relação ao horário comercial local.
Prévia no fuso certo
Ao validar, pergunte sempre:
- Qual engine executa este job?
- Qual fuso essa engine usa?
- Quais são as próximas três execuções nesse fuso e em UTC?
Resumo
Documente fuso + plataforma ao lado de cada linha cron em runbooks. “Todo dia às 9” não significa nada sem saber de qual relógio.