Po pierwsze, zrozum, że we współczesnej terminologii należy mówić UTC zamiast GMT. Są one w większości równoważne, z tym wyjątkiem, że czas UTC jest dokładniej zdefiniowany. Zarezerwuj termin GMT, aby odnosić się do części strefy czasowej w Wielkiej Brytanii, która obowiązuje w miesiącach zimowych z przesunięciem UTC+0.
Teraz twoje pytanie. UTC niekoniecznie jest najlepszym sposobem przechowywania wszystkich wartości daty i godziny. Działa szczególnie dobrze w przypadku przeszłości wydarzenia lub dla przyszłych absolutnych wydarzeniami, ale nie działa to zbyt dobrze w przypadku przyszłych lokalnych wydarzenia — zwłaszcza przyszłe cykliczne wydarzenia.
Pisałem o tym w innej odpowiedzi ostatnio i jest jednym z nielicznych wyjątków, w których czas lokalny ma większy sens niż UTC. Głównym argumentem jest „problem z budzikiem”. Jeśli ustawisz budzik według czasu UTC, w dniu przejścia na czas letni obudzisz się godzinę wcześniej lub późno. Dlatego większość ludzi ustawia budziki według czasu lokalnego.
Oczywiście nie możesz po prostu przechowuj czas lokalny, jeśli pracujesz z danymi z całego świata. Powinieneś przechowywać kilka różnych rzeczy:
- Czas lokalny wydarzenia cyklicznego, np. „08:00”
- Strefa czasowa, w której wyrażany jest czas lokalny, na przykład „Ameryka/Nowy_Jork”
- Wzorzec powtarzalności, w dowolnym formacie, który ma sens dla Twojej aplikacji, na przykład codziennie, co dwa tygodnie lub w trzeci czwartek miesiąca itp.
- Następny natychmiastowy Odpowiednik daty i czasu UTC, najlepiej, jak możesz to zaprojektować.
- Być może, ale nie zawsze, lista przyszłych dat i godzin zdarzeń w czasie UTC, z przewidywanym okresem w przyszłość (być może tydzień, może 6 miesięcy, może rok lub dwa, w zależności od potrzeb).
W przypadku dwóch ostatnich zrozum, że odpowiednik UTC dowolnej lokalnej daty/godziny może ulec zmianie, jeśli rząd odpowiedzialny za tę strefę czasową zdecyduje się coś zmienić. Ponieważ co roku jest wiele aktualizacji baz danych stref czasowych, warto zaplanować subskrybuj ogłoszenia o aktualizacjach i zaktualizuj bazę danych stref czasowych regularnie. Za każdym razem, gdy aktualizujesz dane strefy czasowej, musisz ponownie obliczyć czasy UTC dla wszystkich przyszłych wydarzeń.
Posiadanie odpowiedników UTC jest ważne, jeśli planujesz wyświetlać dowolną listę wydarzeń obejmujących więcej niż jedną strefę czasową. To są wartości, o które zapytasz, aby zbudować tę listę.
Inną kwestią do rozważenia jest to, że jeśli zdarzenie jest zaplanowane na czas lokalny, który ma miejsce podczas przejścia na czas letni, będziesz musiał zdecydować, czy zdarzenie ma miejsce w pierwszej instancji (zwykle), czy w drugiej instancji (czasami). lub jedno i drugie (rzadko) i wbuduj w swoją aplikację mechanizm zapewniający, że zdarzenie nie zostanie uruchomione dwa razy, chyba że tego chcesz.
Jeśli szukałeś prostej odpowiedzi - przepraszam, ale nie ma takiej. Planowanie przyszłych wydarzeń w różnych strefach czasowych to skomplikowane zadanie.
Alternatywne podejście
Kilka osób pokazało mi technikę, w której robią używaj czasu UTC do planowania, co oznacza, że wybierają datę początkową w czasie lokalnym, konwertują ją na czas UTC do przechowywania i przechowują również identyfikator strefy czasowej. Następnie w czasie wykonywania stosują strefę czasową, aby przekonwertować oryginalny czas UTC z powrotem na czas lokalny, a następnie używają tego czasu lokalnego do obliczenia innych cykli, tak jakby był pierwotnie zapisany jak powyżej.
Ta technika działa , wady to:
-
Jeśli istnieje aktualizacja strefy czasowej, która zmienia czas lokalny przed uruchomieniem pierwszej instancji, spowoduje to wyłączenie całego harmonogramu. Można to złagodzić, wybierając czas w przeszłości dla „pierwszej” instancji, tak aby druga instancja była naprawdę pierwszą.
-
Jeśli czas jest naprawdę „czasem ruchomym”, który powinien podążać za użytkownikiem (na przykład w budziku w telefonie komórkowym), nadal będziesz musiał przechowywać informacje o strefie czasowej dla strefy, w której została pierwotnie utworzona — nawet jeśli to nie jest strefa, w której chcesz biec.
-
Dodaje dodatkową złożoność bez żadnych korzyści. Zarezerwowałbym tę technikę dla sytuacji, w których mogłeś mieć harmonogram działający tylko w UTC, do którego próbujesz zmodernizować obsługę stref czasowych.
