Właściwe planowanie przyszłych zadań według czasu lokalnego, z uwzględnieniem stref czasowych i czasu letniego, jest bardzo złożonym tematem. Pisałem o tym wcześniej z perspektywy programowej na Stack Overflow tu i tutaj .
Podsumuję z perspektywy nieprogramowej:
Zdefiniuj wzorce nawrotów według czasu lokalnego - nie UTC . Na przykład, jeśli ustawisz codzienny budzik, aby budził cię codziennie o 8:00 rano, nie chcesz budzić się godzinę wcześniej ani godzinę później po zmianie czasu na letni. Jeśli jestem w strefie czasowej USA Pacyfiku, nie mogę zaplanować godziny 16:00 UTC, ponieważ po przejściu musiałby przełączyć się na godzinę 15:00 UTC, aby zachować ten sam czas lokalny o godzinie 8:00.
Zdefiniuj strefę czasową reprezentowaną przez czas „lokalny”. Nie zakładaj, że lokalna strefa czasowa serwera jest tą samą strefą czasową, która ma znaczenie dla użytkownika końcowego.
Wyświetl czas lokalny na datę i godzinę UTC dla każdego zdarzenia, w którym ma zostać uruchomione zdarzenie.
Prawie zawsze zrobisz to dla następnego natychmiastowego wystąpienia, na przykład możesz użyć zegara UTC, aby określić rzeczywistą natychmiastową godzinę uruchomienia.
W niektórych przypadkach możesz także chcieć wyświetlić kilka kolejnych (lub wielu) wystąpień, takich jak 5 kolejnych wystąpień lub wszystkie wystąpienia na następny rok. (Ta część jest bardzo specyficzna dla wymagań aplikacji.)
Przygotuj strategię (stałą lub konfigurowalną) określającą, co zrobić w przypadku zdarzeń, które wypadają w czasie zmiany czasu na letni :
W przypadku przejścia „wiosennego do przodu” występuje brak czasu lokalnego, gdy wystąpienie może nie istnieć. Na przykład w czasie pacyficznym w USA codzienne zadanie zaplanowane na godzinę 2:00 czasu lokalnego nie będzie istniało 9 marca 2014 r. W większości przypadków będziesz chciał przyspieszyć ten czas o kwotę oszczędności (zwykle 1 godzinę ), więc tego dnia uruchomi się o 3:00, ale w następnym przypadku powróci do działania o 2:00. (Jest jednak całkiem możliwe, że będziesz potrzebować innej strategii.)
W przypadku przejścia „rezerwowego” zachodzi na siebie powielony czas lokalny, gdy zdarzenie może występować dwukrotnie . Na przykład w czasie pacyficznym w USA codzienne zadanie zaplanowane na godzinę 1:00 będzie miało dwa możliwe czasy, które mogłoby zostać uruchomione 2 listopada 2014 r. W większości przypadków będzie ono uruchamiane przy pierwszym wystąpieniu 1 : 00 AM PDT i pomiń następne wystąpienie 1:00 PST tego samego dnia. (Ale znowu, może chcieć inną strategię, jak działa na drugim wystąpieniu, czy działa w obu. YMMV)
Przygotuj się na ponowne obliczenie wszystkich czasów UTC wystąpienia, jeśli kiedykolwiek będziesz potrzebować zaktualizować dane strefy czasowej. W IANA / Olson TZDB gasi wielu aktualizacji rocznie, ponieważ rządy zmiany ich umysły świata cały czas o ich przesunięcia strefy czasowej i zasad dotyczących czasu letniego. Nie można zakładać przez określony czas w przyszłości, że zasady się nie zmienią .
Pamiętaj, aby zasubskrybować ogłoszenia o wydaniach danych stref czasowych i mieć proces ich stosowania w systemach i / lub aplikacjach.
W tradycyjnym otoczeniu korporacyjnym powinien to być obowiązek personelu działu IT.
W zależności od środowiska możesz uzyskiwać te dane poprzez tzdataaktualizacje pakietu Linux, JRE Java lub tzupdater lub dowolną liczbę innych kanałów. Czasami zależy od środowiska, a czasem od platformy programistycznej, takiej jak pakiet PECL timzonedb dla PHP i wiele innych.
Microsoft ma własne dane strefy czasowej. W systemie Windows, jeśli korzystasz TimeZoneInfoz .NET (na przykład), używasz tych danych. Aktualizacje pochodzą stąd , a także są automatycznie wypychane przez Windows Update, więc powinieneś uważać na te, abyś wiedział, kiedy / jeśli chcesz przeliczyć.
Z tego wszystkiego rozumieć, nie jest jeszcze scenariusz, w którym chcesz zaplanować tylko przez UTC, a to jest dla BEZWZGLĘDNYCH zdarzeń przyszłych. Przykłady:
Zadanie uruchamiane co X godzin lub co X minut.
Czas rozpoczęcia i zakończenia wschodu słońca lub inne zjawisko astronomiczne.
Okno bezpieczeństwa wrażliwe na czas, na przykład podczas przesyłania poufnych informacji innej stronie w ustalonym czasie.
Harmonogram zadań systemu Windows
Windows niekoniecznie postępuje właściwie. Zwróć uwagę na sposób definiowania wyzwalacza:
Po zaznaczeniu pola „Synchronizuj w różnych strefach czasowych” zadanie jest planowane tylko przez UTC. (Wszystkie czasy są nadal wyświetlane jako czas lokalny, ale są przechowywane jako UTC.) To dlatego, jak wcześniej nazwałem, zdarzeniem „absolutnym”.
Jeśli pozostawisz to pole niezaznaczone, użyje lokalnej strefy czasowej komputera, na którym działa kod. Nie daje żadnej opcji określania strefy czasowej, więc nie jest to bardzo dobra implementacja IMHO.
Nie jestem do końca pewien, czy jest to zachowanie DST, ale poeksperymentuję i skontaktuję się z Tobą. Prawdopodobnie robi to, co opisałem powyżej, ale niekoniecznie.
Agent SQL
Program planujący agenta SQL jest jeszcze gorszy, ponieważ pozwala tylko na użycie czasu lokalnego serwera. Ponownie nie można określić żadnych stref czasowych i nie można również podać UTC.
Zostało ono wymagane , ale nie są akceptowane.