Die richtige Planung zukünftiger Aufgaben nach Ortszeit unter Berücksichtigung von Zeitzonen und Sommerzeit ist ein sehr komplexes Thema. Ich habe hier und hier bereits aus Programmiersicht über Stack Overflow darüber geschrieben .
Ich werde aus einer nicht programmierbaren Perspektive zusammenfassen:
Definieren Sie Ihre Wiederholungsmuster nach Ortszeit - nicht nach UTC . Wenn Sie beispielsweise einen täglichen Wecker einstellen, der Sie jeden Tag um 8:00 Uhr aufweckt, möchten Sie nach einer Sommerzeitumstellung nicht eine Stunde früher oder eine Stunde später aufwecken. Wenn ich mich in der US-Pazifik-Zeitzone befinde, kann ich keinen Zeitplan für 16.00 Uhr UTC erstellen, da nach der Umstellung auf 15.00 Uhr UTC umgestellt werden muss, um die Ortszeit von 8.00 Uhr zu halten.
Definieren Sie die Zeitzone, die die "lokale" Zeit darstellt. Nehmen Sie nicht an, dass die lokale Zeitzone des Servers dieselbe Zeitzone ist, die für den Endbenutzer von Bedeutung ist.
Projizieren Sie die Ortszeit auf ein UTC-Datum und eine UTC-Zeit für jedes Ereignis, das das Ereignis auslösen soll.
Sie werden dies fast immer für das nächste unmittelbare Ereignis tun, sodass Sie die UTC-Uhr verwenden können, um den tatsächlichen Ausführungszeitpunkt zu bestimmen.
In einigen Fällen möchten Sie möglicherweise auch die nächsten (oder mehrere) Instanzen projizieren, z. B. die nächsten 5 Vorkommen oder alle Vorkommen für das nächste Jahr. (Dieser Teil ist sehr spezifisch für die Anforderungen der Anwendung.)
Verfügen Sie über eine Strategie (entweder fest oder konfigurierbar) für Vorkommnisse, die zum Zeitpunkt eines Übergangs zwischen Sommer- und Winterzeit auftreten:
Für den Übergang "Vorwärtsspringen" gibt es eine Lücke, in der die Ortszeit fehlt, wenn das Ereignis möglicherweise nicht vorhanden ist. In der US-Pazifik-Zeit beispielsweise ist eine tägliche Aufgabe, die um 2:00 Uhr Ortszeit ausgeführt werden soll, am 9. März 2014 nicht vorhanden. In den meisten Fällen möchten Sie diese Zeit um den gesparten Betrag vorverlegen (normalerweise 1 Stunde) ), an diesem Tag wird es um 3:00 Uhr morgens ausgeführt, in der nächsten Instanz wird es jedoch wieder um 2:00 Uhr morgens ausgeführt. (Es ist jedoch durchaus möglich, dass Sie hierfür eine andere Strategie wünschen.)
Für den "Fallback" -Übergang gibt es eine Überlappung der duplizierten Ortszeit, wenn das Vorkommen möglicherweise zweimal vorhanden ist . In der US-Pazifik-Zeit kann ein täglicher Task, der um 01:00 Uhr ausgeführt werden soll, am 2. November 2014 zu zwei möglichen Zeitpunkten ausgeführt werden. In den meisten Fällen möchten Sie ihn beim ersten Auftreten von 1 ausführen : 00 PDT und überspringen Sie das nächste Auftreten von 1:00 PST des gleichen Datums. ( Möglicherweise möchten Sie aber auch eine andere Strategie, z. B. beim zweiten Auftreten oder in beiden. YMMV)
Bereiten Sie sich darauf vor, alle UTC-Zeiten Ihres Auftretens neu zu berechnen, wenn Sie jemals Ihre Zeitzonendaten aktualisieren müssen. Die IANA / Olson TZDB veröffentlicht jedes Jahr mehrere Updates, da die Regierungen der Welt ihre Meinung zu Zeitzonenverschiebungen und Sommerzeitregeln ständig ändern. Sie können nicht für einen bestimmten Zeitraum in der Zukunft davon ausgehen, dass sich die Regeln nicht ändern .
Stellen Sie sicher, dass Sie Ankündigungen von Zeitzonendaten-Releases abonnieren und über ein Verfahren verfügen, um sie auf Ihre Systeme und / oder Anwendungen anzuwenden.
In einem traditionellen Unternehmensumfeld sollte dies in der Verantwortung des IT-Betriebspersonals liegen.
Abhängig von Ihrer Umgebung erhalten Sie diese Daten möglicherweise über tzdataLinux-Paketaktualisierungen, über Java JRE oder tzupdater oder über eine beliebige Anzahl anderer Kanäle. Manchmal ist es umgebungsspezifisch und manchmal ist es plattformspezifisch, wie das PECL-Paket timezonedb für PHP und viele andere.
Microsoft hat seine eigenen Zeitzonendaten. Wenn Sie unter Windows TimeZoneInfobeispielsweise .NET verwenden, verwenden Sie diese Daten. Updates kommen von hier und werden auch automatisch über Windows Update verteilt. Achten Sie daher auf diese, damit Sie wissen, wann bzw. ob Sie eine Neuberechnung durchführen müssen.
Wenn all dies verstanden ist, gibt es immer noch ein Szenario, in dem Sie nur nach UTC planen würden, und zwar für ABSOLUTE zukünftige Ereignisse. Beispiele:
Ein Job, der alle X Stunden oder alle X Minuten ausgeführt wird.
Start- und Stoppzeiten des Sonnenaufgangs oder andere astronomische Phänomene.
Ein zeitkritisches Sicherheitsfenster, z. B. beim Übertragen vertraulicher Informationen an eine andere Partei zu einem festgelegten Zeitpunkt.
Windows-Taskplaner
Windows tut nicht unbedingt das Richtige. Achten Sie darauf, wie Sie den Auslöser definieren:
Wenn Sie das Kontrollkästchen "Über Zeitzonen hinweg synchronisieren" aktivieren, wird die Aufgabe nur von UTC geplant. (Alle Zeiten werden immer noch als Ortszeit angezeigt, aber als UTC gespeichert .) Dies ist also für das, was ich früher als "absolutes" Ereignis bezeichnet habe.
Wenn Sie dieses Kontrollkästchen nicht aktivieren, wird die lokale Zeitzone des Computers verwendet, auf dem der Code ausgeführt wird. Sie haben keine Möglichkeit, die Zeitzone anzugeben, daher ist dies meiner Meinung nach keine sehr gute Implementierung.
Ich bin mir nicht ganz sicher, ob es sich um eine Sommerzeit handelt, aber ich werde experimentieren und darauf zurückkommen. Es macht wahrscheinlich das, was ich oben beschrieben habe, aber nicht unbedingt.
SQL Agent
Der SQL Agent-Scheduler ist sogar noch schlimmer, da Sie nur die lokale Serverzeit verwenden können. Auch hier können keine Zeitzonen angegeben werden, und Sie können auch keine UTC-Zeit angeben.
Es wurde angefordert , aber nicht akzeptiert.