Nejprve si prosím uvědomte, že v moderní terminologii byste měli říkat UTC místo GMT. Většinou jsou ekvivalentní, až na to, že UTC je přesněji definováno. Vyhraďte si termín GMT pro označení části časového pásma ve Spojeném království, které je platné během zimních měsíců s offsetem UTC+0.
Nyní k vaší otázce. UTC není nutně nejlepší způsob, jak uložit všechny hodnoty data a času. Obzvláště dobře funguje pro minulost události nebo pro budoucí absolutní události, ale pro budoucí místní to tak skvěle nefunguje události – zejména budoucí opakující se události.
Napsal jsem o tom v jiné odpovědi v poslední době a je jedním z mála výjimečných případů, kdy místní čas dává větší smysl než UTC. Hlavním argumentem je „problém s budíkem“. Pokud si budík nastavíte podle UTC, budete v den přechodu na letní čas vstávat o hodinu dříve nebo později. To je důvod, proč si většina lidí nastavuje budíky podle místního času.
Samozřejmě nemůžete jen uložte si místní čas, pokud pracujete s daty z celého světa. Měli byste uložit několik různých věcí:
- Místní čas opakující se události, například „08:00“
- Časové pásmo, ve kterém je vyjádřen místní čas, například „Amerika/New_York“
- Vzor opakování v jakémkoli formátu, který má pro vaši aplikaci smysl, například denně, jednou za dva týdny nebo třetí čtvrtek v měsíci atd.
- Další okamžité Ekvivalent data a času UTC podle toho nejlepšího, co můžete promítnout.
- Možná, ale ne vždy, seznam budoucích dat a časů událostí UTC, promítnutých do určitého předem definovaného období do budoucnosti (možná týden, možná 6 měsíců, možná rok nebo dva, v závislosti na vašich potřebách). li>
U posledních dvou vězte, že ekvivalent UTC jakéhokoli místního data/času se může změnit, pokud se vláda odpovědná za toto časové pásmo rozhodne něco změnit. Vzhledem k tomu, že se databáze časových pásem aktualizuje každý rok, budete chtít mít plán na přihlásit se k odběru oznámení o aktualizacích a aktualizovat databázi časových pásem pravidelně. Kdykoli aktualizujete data svého časového pásma, budete muset přepočítat ekvivalentní časy UTC všech budoucích událostí.
Mít ekvivalenty UTC je důležité, pokud plánujete zobrazit jakýkoli druh seznamu událostí zahrnujících více než jedno časové pásmo. To jsou hodnoty, na které se budete dotazovat při sestavování tohoto seznamu.
Dalším bodem, který je třeba zvážit, je, že pokud je událost naplánována na místní čas, ke které dojde během přechodu na letní čas, budete se muset rozhodnout, zda se událost vyskytne v první instanci (obvykle), nebo v druhé instanci (někdy). nebo obojí (zřídka) a zabudujte do své aplikace mechanismus, který zajistí, že se událost nespustí dvakrát, pokud si to nepřejete.
Pokud jste hledali jednoduchou odpověď – omlouvám se, ale žádná neexistuje. Plánování budoucích událostí v různých časových pásmech je složitý úkol.
Alternativní přístup
Několik lidí mi ukázalo techniku, kterou dělají používat pro plánování čas UTC, což znamená, že vyberou počáteční datum v místním čase, převedou ho na UTC, aby se uložilo, a také uloží ID časové zóny. Potom za běhu použijí časové pásmo k převodu původního času UTC zpět na místní čas a poté tento místní čas použijí k výpočtu ostatních opakování, jako by to byl ten, který byl původně uložen, jak je uvedeno výše.
Zatímco tato technika bude fungovat , nevýhody jsou:
-
Pokud existuje aktualizace časového pásma, která změní místní čas před spuštěním první instance, zruší celý plán. To lze zmírnit výběrem času v minulosti pro „první“ instanci, takže druhá instance je skutečně první.
-
Pokud je čas skutečně „plovoucím časem“, který by měl uživatele sledovat (například v budíku na mobilním telefonu), stále byste museli ukládat informace o časovém pásmu pro pásmo, ve kterém byl původně vytvořen – i když to není zóna, ve které chcete běžet.
-
Přidává další složitost bez jakýchkoli výhod. Tuto techniku bych si vyhradil pro situace, kdy možná máte plánovač pouze pro UTC, do kterého se snažíte dodatečně začlenit podporu časového pásma.