Ferramentas de desenvolvedor · Gerador Crontab
Por que o cron não possui campo de fuso horário: hora local, CRON_TZ e contêineres em UTC
· Fundo
cron fusos horários agendamento
Uma expressão cron não possui fuso horário, portanto, os mesmos cinco campos significam momentos diferentes em hosts diferentes. Esta postagem explica qual relógio o cron usa, a extensão CRON_TZ e por que os contêineres alteram a resposta.
Os mesmos campos produzem diferentes instantes de visualização quando a zona selecionada muda
`0 9 * * *` contém uma hora, mas nenhuma localização. Em ToolAcre, escolher UTC ou Ásia/Tokyo deixa os cinco campos inalterados enquanto altera o instante representado por cada candidato a relógio de parede 09:00. Portanto, um relatório pode aparecer com horas de intervalo quando dois ambientes interpretam os mesmos rótulos locais em zonas diferentes.
O painel torna essa dependência explícita com um seletor “Mostrar próximas execuções”. Use a zona da máquina pretendida ao revisar a programação e registre essa suposição ao lado da expressão. A seleção afeta apenas a visualização do navegador; ele não está incorporado no texto cron copiado.
A expressão não contém zona; a seleção do relógio do daemon externo não está configurada aqui
Existem exatamente cinco especificações de campo, nenhuma com fuso horário nomeado. `nextRuns` aceita zona como uma opção separada e o padrão é o ambiente host visto por JavaScript. Esta separação prova que o contexto da zona é externo à expressão no modelo de ToolAcre.
A pasta de trabalho afirmava qual relógio cada daemon lê. Este repositório não pode configurar ou inspecionar um daemon, portanto não estabelece esse comportamento universal. Ele só pode aconselhar a correspondência da zona de visualização com a interpretação documentada do alvo e a verificação do agendador instalado de forma independente.
O suporte CRON_TZ está fora deste analisador e não é reivindicado
`CRON_TZ` não é analisado. Inserir na caixa de expressão falha porque não são cinco campos e nenhum controle por campo armazena uma diretiva. A afirmação da pasta de trabalho de que uma implementação a suporta enquanto outras não requer fontes não presentes aqui.
Se um destino documentar uma diretiva de fuso horário, configure-a e teste-a lá. Não espere que ToolAcre preserve a diretiva ao copiar uma expressão. Mantenha os metadados da zona adjacentes ao agendamento até que a configuração específica do destino seja revisada e implantada.
A semântica do ambiente TZ não é modelada
Uma atribuição `TZ` está igualmente fora do escopo. O navegador usa uma opção `timeZone` explícita para formatação e conversão, não uma linha de ambiente dentro de um arquivo crontab. Ele não pode dizer se uma atribuição altera a avaliação do cronograma, a saída do comando ou nenhuma delas em outro sistema.
Esta correção evita uma suposição sutil, mas dispendiosa. Nomes semelhantes não implicam funções idênticas. Trate a seleção da zona do agendador e o ambiente do processo como questões separadas e responda a ambos a partir da implementação de destino, em vez de a partir de um gerador de expressão.
Os padrões de contêiner e nuvem exigem evidências de destino
Contêineres e imagens de nuvem não são inspecionados pela rota. Nenhum soquete Docker, relógio de host ou serviço de metadados é consultado. As afirmações de que o padrão é UTC podem ser verdadeiras em uma implantação específica, mas não podem ser generalizadas a partir de `Intl.DateTimeFormat` em execução no navegador de um leitor.
Capture a zona-alvo real por meio de suas ferramentas e configurações documentadas. Em seguida, selecione o mesmo nome IANA em ToolAcre quando disponível. Uma lista de zonas do navegador reflete o que seu mecanismo sabe; isso não prova que o destino contém dados ou configurações de zona idênticas.
Exemplo resolvido: visualizar 09:00 em duas zonas selecionadas sem conversão sazonal codificada
Mantenha `0 9 * * *` fixo e visualize um resultado em UTC, depois na América/New_York. Cada lista mostra 09:00 como tempo de parede, mas os instantes de época diferem pelo deslocamento de zona aplicável. Evite publicar uma conversão de hora permanente porque as compensações regionais podem mudar entre as datas.
Os testes demonstram esse princípio com UTC e meia-noite de Tóquio e com um trabalho diário de Londres em uma mudança futura. Use os candidatos ao vivo para as datas em análise. Se a implantação converter a programação em uma hora fixa de UTC, documente a limitação sazonal em vez de sugerir que um valor preserva 09:00 local para sempre.
O tratamento do candidato DST é um comportamento de visualização do ToolAcre, não uma garantia do daemon
ToolAcre cria candidatos como componentes locais do calendário e os converte por meio de dados da zona do navegador. Um horário de primavera inexistente é omitido e uma hora diária comum permanece a mesma hora local durante uma transição testada. Esses são fatos de implementação preliminares.
Eles não são garantias de execução para um daemon ou agendador de nuvem. Verifique a política de transição onde o trabalho será executado. A visualização pode revelar um risco e fornecer instantes esperados, enquanto o agendador implantado fornece a observação oficial sobre se uma ação foi iniciada.
Conclusão: uma programação só fica completa com seu fuso horário – crie os campos no gerador e registre o fuso horário ao lado deles
Um agendamento é operacionalmente incompleto sem contexto de zona, mesmo que seus cinco campos estejam sintaticamente completos. ToolAcre representa essa verdade mantendo a zona em um seletor separado e mostrando a lista de relógios resultante. A expressão copiada por si só não pode conter a escolha.
Registre a expressão e a zona juntas, verifique a configuração de destino e revisite os candidatos próximos às alterações de deslocamento. O gerador cria e explica horários; ele não define o relógio do servidor, não escreve diretivas de fuso horário nem promete execução. Esse limite mantém a visualização útil sem exagerar no controle.