O agendamento adequado de tarefas futuras por hora local, levando em consideração os fusos horários e o horário de verão, é um assunto muito complexo. Eu escrevi sobre isso antes de uma perspectiva de programação no Stack Overflow aqui e aqui .
Vou resumir de uma perspectiva de não programação:
Defina seus padrões de recorrência pela hora local - não pelo UTC . Por exemplo, se você definir um despertador diário para acordá-lo às 8:00 todos os dias, não deseje acordar uma hora mais cedo ou uma hora depois de uma transição de horário de verão. Se eu estiver no fuso horário do Pacífico dos EUA, não posso agendar para as 16:00 UTC, porque após a transição, será necessário mudar para as 15:00 UTC para manter a mesma hora local às 08:00.
Defina o fuso horário que o horário "local" representa. Não assuma que o fuso horário local do servidor é o mesmo fuso horário que importa para o usuário final.
Projete a hora local com uma data e hora UTC para cada ocorrência que você deseja que o evento seja acionado.
Você quase sempre fará isso para a próxima ocorrência imediata, para poder usar o relógio UTC para determinar o instante real na hora de executar.
Em alguns casos, convém também projetar as próximas várias (ou muitas) instâncias, como as próximas 5 ocorrências ou todas as ocorrências para o próximo ano. (Esta parte é altamente específica para os requisitos do aplicativo.)
Tenha uma estratégia em prática (fixa ou configurável), do que fazer para ocorrências que caem no momento de uma transição de horário de verão :
Para a transição "primavera adiante", há uma diferença de horário local ausente, quando a ocorrência pode não existir. Por exemplo, no horário do Pacífico dos EUA, uma tarefa diária agendada para ser executada às 02:00, horário local, não existirá em 9 de março de 2014. Na maioria dos casos, convém avançar esse horário pelo valor da economia (geralmente 1 hora ), nesse dia , será executado às 3:00, mas voltará a ser executado às 2:00 na próxima instância. (No entanto, é perfeitamente possível que você deseje uma estratégia diferente para isso.)
Para a transição de "retorno", há uma sobreposição da hora local duplicada, quando a ocorrência pode existir duas vezes . Por exemplo, no horário do Pacífico dos EUA, uma tarefa diária programada para ser executada às 01:00 terá dois horários possíveis em 2 de novembro de 2014. Na maioria dos casos, você desejará executar na primeira ocorrência de 1 : 00 PDT e pule a próxima ocorrência de 01:00 PST da mesma data. (Mas, novamente, você pode querer uma estratégia diferente, como executar na segunda ocorrência ou executar nas duas. YMMV)
Esteja preparado para recalcular todos os seus horários UTC de ocorrência, se precisar atualizar seus dados de fuso horário. O IANA / Olson TZDB lança várias atualizações todos os anos porque os governos do mundo mudam de idéia o tempo todo sobre as compensações de fuso horário e as regras de horário de verão. Você não pode assumir, por um período específico de tempo, que as regras não serão alteradas .
Certifique-se de assinar anúncios de liberações de dados de fuso horário e tenha um processo para aplicá-las aos seus sistemas e / ou aplicativos.
Em um ambiente corporativo tradicional, isso deve ser de responsabilidade da equipe de operações de TI.
Dependendo do seu ambiente, você pode obter esses dados por meio de tzdataatualizações de pacotes Linux, por meio de Java JRE ou tzupdater ou qualquer outro número de outros canais. Às vezes, é específico do ambiente e, às vezes, da plataforma de programação, como o pacote PECL do timezonedb para PHP e muitos outros.
A Microsoft possui seus próprios dados de fuso horário. No Windows, se você estiver usando o TimeZoneInfo.NET (por exemplo), estará usando esses dados. As atualizações vêm daqui e também são enviadas automaticamente pelo Windows Update; portanto, você deve ficar de olho nisso para saber quando / se precisar recalcular.
Com tudo isso entendido, não é ainda um cenário onde você iria agendar apenas pela UTC, e que é para ABSOLUTAS eventos futuros. Exemplos:
Um trabalho que é executado a cada X horas ou a cada X minutos.
Horário de início e fim do nascer do sol ou outro fenômeno astronômico.
Uma janela de segurança sensível ao tempo, como ao transmitir informações confidenciais para outra parte em um horário previamente combinado.
Agendador de tarefas do Windows
O Windows não está necessariamente fazendo a coisa certa. Preste atenção em como você define o gatilho:
Quando você marca a caixa "Sincronizar entre fusos horários", a tarefa é agendada apenas pelo UTC. (Todos os horários ainda são mostrados como horário local, mas são armazenados como UTC.) Portanto, isso é para o que eu chamei anteriormente de evento "absoluto".
Quando você deixar essa caixa desmarcada, ela usará o fuso horário local do computador em que o código está sendo executado. Ele não oferece nenhuma opção para especificar o fuso horário, portanto, essa não é uma IMHO de implementação muito boa.
Não tenho exatamente certeza do seu comportamento no horário de verão, mas vou experimentar e responder a você sobre isso. Provavelmente faz o que descrevi acima, mas não necessariamente.
Agente SQL
O agendador do SQL Agent é ainda pior, pois permite apenas o uso do horário do servidor local. Novamente, nenhum fuso horário pode ser especificado e você também não pode especificar o UTC.
Foi solicitado , mas não aceito.