La corretta pianificazione delle attività future in base all'ora locale, tenendo conto dei fusi orari e dell'ora legale, è un argomento molto complesso. Ne ho già parlato da una prospettiva di programmazione su Stack Overflow qui e qui .
Riassumo in una prospettiva non programmativa:
Definisci i tuoi schemi di ricorrenza in base all'ora locale , non all'ora UTC . Ad esempio, se imposti una sveglia giornaliera per svegliarti alle 8:00 tutti i giorni, non vuoi svegliarti un'ora prima o un'ora dopo una transizione di ora legale. Se mi trovo nel fuso orario degli Stati Uniti del Pacifico, non posso programmare per le 4:00 PM UTC, perché dopo la transizione dovrebbe passare alle 3:00 PM UTC per mantenere la stessa ora locale 8:00 AM.
Definire il fuso orario rappresentato dall'ora "locale". Non dare per scontato che il fuso orario locale del server sia lo stesso fuso orario che conta per l'utente finale.
Proiettare l'ora locale su una data e ora UTC per ogni ricorrenza che si desidera attivare l'evento.
Lo farai quasi sempre per la prossima occorrenza immediata, in modo tale da poter utilizzare l'orologio UTC per determinare l'istante reale in tempo per l'esecuzione.
In alcuni casi, potresti voler proiettare anche le successive (o molte) istanze successive, come le successive 5 occorrenze o tutte le occorrenze per l'anno successivo. (Questa parte è altamente specifica per i requisiti dell'applicazione.)
Predisporre una strategia (fissa o configurabile), che cosa fare per gli eventi che cadono al momento di una transizione dell'ora legale :
Per la transizione "molla in avanti", c'è un gap di ora locale mancante quando l'evento potrebbe non esistere. Ad esempio, nell'ora del Pacifico degli Stati Uniti, un'attività giornaliera pianificata per l'esecuzione alle 2:00 ora locale non esisterà il 9 marzo 2014. Nella maggior parte dei casi, ti consigliamo di anticipare tale importo in base all'importo del risparmio (di solito 1 ora ), quindi quel giorno verrà eseguito alle 3:00, ma tornerà in esecuzione alle 2:00 nella prossima istanza. (Tuttavia, è del tutto possibile che tu voglia una strategia diversa per questo.)
Per la transizione "fallback", c'è una sovrapposizione di ora locale duplicata quando l'evento potrebbe esistere due volte . Ad esempio, in US Pacific Time, un'attività giornaliera pianificata per essere eseguita all'1: 00 avrà due possibili volte che potrebbe essere eseguita il 2 novembre 2014. Nella maggior parte dei casi, ti consigliamo di eseguire alla prima occorrenza di 1 : 00 AM PDT e salta la prossima occorrenza di 1:00 AM PST della stessa data. (Ma ancora una volta, potresti volere una strategia diversa, come l'esecuzione alla seconda occorrenza o l'esecuzione in entrambe. YMMV)
Preparati a ricalcolare tutti i tuoi orari UTC di occorrenza se dovessi mai aggiornare i dati del fuso orario. I IANA / Olson TZDB mette fuori più aggiornamenti ogni anno perché i governi del mondo cambiano le loro menti tutto il tempo sulle loro offset di fuso orario e le regole di ora legale. Non puoi assumere per un periodo di tempo specifico in futuro che le regole non cambieranno .
Assicurati di iscriverti per gli annunci dei rilasci di dati di fuso orario e di avere una procedura per applicarli ai tuoi sistemi e / o applicazioni.
In un ambiente aziendale tradizionale, questa dovrebbe essere la responsabilità del personale delle operazioni IT.
A seconda del proprio ambiente, è possibile che si ottengano questi dati tramite gli tzdataaggiornamenti del pacchetto Linux, tramite Java JRE o tzupdater o un numero qualsiasi di altri canali. A volte è specifico per l'ambiente, a volte è specifico per la piattaforma di programmazione, come il pacchetto PECL timezonedb per PHP e molti altri.
Microsoft ha i propri dati sul fuso orario. Su Windows, se stai utilizzando TimeZoneInfo.NET (ad esempio), stai utilizzando questi dati. Gli aggiornamenti provengono da qui e vengono anche inviati automaticamente tramite Windows Update, quindi dovresti tenere d'occhio quelli in modo da sapere quando / se devi ricalcolare.
Con tutto che ha capito, non v'è ancora uno scenario in cui si desidera programmare solo con UTC, e che è per ASSOLUTI eventi futuri. Esempi:
Un lavoro che viene eseguito ogni X ore o ogni X minuti.
Orari di inizio e fine dell'alba o altri fenomeni astronomici.
Una finestra di sicurezza sensibile al tempo, ad esempio quando si trasmettono informazioni sensibili a un'altra parte in un momento prestabilito.
Utilità di pianificazione di Windows
Windows non sta necessariamente facendo la cosa giusta. Presta attenzione a come definisci il trigger:
Quando si seleziona la casella "Sincronizza tra fusi orari", l'attività viene pianificata solo da UTC. (Tutti gli orari sono ancora visualizzati come ora locale, ma sono memorizzati come UTC.) Quindi questo è per quello che in precedenza ho chiamato un evento "assoluto".
Quando la casella viene lasciata deselezionata, verrà utilizzato il fuso orario locale del computer su cui è in esecuzione il codice. Non ti dà alcuna opzione per specificare il fuso orario, quindi non è un'ottima IMHO di implementazione.
Non sono esattamente sicuro del comportamento dell'ora legale, ma sperimenterò e ti ricontatterò. Probabilmente fa ciò che ho descritto sopra, ma non necessariamente.
Agente SQL
La pianificazione di SQL Agent è ancora peggio, nel senso che solo consente di utilizzare ora locale del server. Ancora una volta, non è possibile specificare fusi orari e non è nemmeno possibile specificare UTC.
È stato richiesto , ma non accettato.