Gerador Cron Timezone Shifter

Conversão de fuso horário em cron

O cron do Linux interpreta as expressões no fuso horário local do servidor. A maioria esmagadora dos servidores cloud roda em UTC, mas a regra de negócio quase sempre vive em um fuso regional — "rode o relatório diário às 9h de São Paulo", "dispare o digest semanal sexta às 17h de Nova York". O descasamento causa um dos bugs operacionais mais comuns: uma entrada cron que pula uma hora duas vezes por ano porque ninguém lembrou do horário de verão, ou que roda às 6h locais porque alguém esqueceu de converter para UTC.

Na prática, "diariamente 9h em São Paulo" (UTC-3, sem DST) vira no cron do servidor UTC 0 12 * * *. "Sexta 17h em Nova York" é mais chato — é 0 22 * * 5 no inverno (EST) mas 0 21 * * 5 no verão (EDT). Não existe expressão fixa única. Por isso schedulers timezone-aware foram criados.

DST: o inimigo eterno

• Brasil não tem mais horário de verão desde 2019 (Decreto 9.772). Um cron exclusivamente em BRT agora é perfeitamente estável o ano inteiro — uma simplificação enorme para o dev brasileiro.
• Estados Unidos trocam no 2º domingo de março (adianta) e no 1º domingo de novembro (atrasa).
• União Europeia troca no último domingo de março e no último domingo de outubro.
• Salto do DST (relógio 2:00 → 3:00): jobs cron na hora faltante são pulados.
• Volta do DST (relógio 2:00 → 1:00): jobs na hora repetida podem rodar duas vezes ou nenhuma, dependendo da implementação do cron.

Mitigação: evite agendar entre 1h e 3h da manhã em região com DST. Se não dá pra evitar, adicione token de idempotência ao job para que a execução duplicada vire no-op.

Schedulers timezone-aware (preferíveis)

Sistemas modernos preferem declarar o fuso pretendido junto da cron, em vez de pré-converter para UTC:

• Cron Linux — defina CRON_TZ=America/Sao_Paulo no topo do crontab; as entradas abaixo rodam naquele fuso.
• systemd timers — OnCalendar=Mon..Fri 09:30 America/Sao_Paulo. Mais limpo que cron quando o fuso importa.
• Kubernetes CronJob — campo spec.timeZone, estável desde Kubernetes 1.27.
• AWS EventBridge Scheduler — aceita o parâmetro ScheduleExpressionTimezone.
• GCP Cloud Scheduler — tem campo timeZone em cada job.

Todos esses tratam transições de DST por você. São estritamente mais seguros do que calcular offset UTC fixo na mão.

Algoritmo de conversão

Quando você precisa converter manualmente (ex: hospedagem compartilhada que só aceita cron UTC), o algoritmo é:

1. Parse da cron no fuso de origem.
2. Escolher uma data representativa (hoje, ou uma data
   dentro da janela DST de destino se a cron atravessa).
3. Computar o offset UTC para aquela data no fuso origem.
4. Aplicar o offset no campo hora; ajustar dia-da-semana
   e dia-do-mês se a hora rolar pra outro dia.
5. Emitir cron em UTC.

Em Python use croniter + zoneinfo; em Node, node-cron com a opção timezone; em Java, Quartz Cron com TimeZone.

Perguntas frequentes

O Brasil ainda tem horário de verão? Não. Foi abolido por decreto federal em 2019. BRT é permanentemente UTC-3 (e UTC-4 em Amazonas/AC), então qualquer cron brasileiro é estável o ano todo.

DSL do container ou CRON_TZ — qual é melhor? Sempre que a plataforma suportar, prefira o campo de DSL/container (k8s spec.timeZone, EventBridge ScheduleExpressionTimezone). É mais visível, declarativo e sobrevive a edições de agenda sem surpresa.

DST realmente quebra cron? Sim — duas vezes por ano. O salto da primavera pula uma hora inteira; a volta do outono pode repetir ou pular, dependendo da implementação. A melhor mitigação é evitar agendar entre 1h e 3h da manhã, ou tornar os jobs idempotentes.

Como testar a conversão? Rode TZ=America/Sao_Paulo date e TZ=UTC date em dois terminais; o offset tem que bater com o que essa ferramenta calculou.