Ten eerste, erken alsjeblieft dat je in moderne terminologie UTC moet zeggen in plaats van GMT. Ze zijn meestal gelijkwaardig, behalve dat UTC nauwkeuriger is gedefinieerd. Reserveer de term GMT om te verwijzen naar het deel van de tijdzone in het Verenigd Koninkrijk dat van kracht is tijdens de wintermaanden met de offset UTC+0.
Nu naar uw vraag. UTC is niet per se de beste manier om alle datum- en tijdwaarden op te slaan. Het werkt vooral goed voor verleden evenementen, of voor toekomstige absolute evenementen, maar het werkt niet zo goed voor toekomstige lokale evenementen - vooral toekomstige terugkerende evenementen.
Ik schreef hierover op een ander antwoord onlangs, en is een van de weinige uitzonderingsgevallen waarin lokale tijd logischer is dan UTC. Het belangrijkste argument is het "wekkerprobleem". Als u uw wekker instelt op UTC, wordt u op de dag van de zomertijdovergangen een uur eerder of later wakker. Dit is de reden waarom de meeste mensen hun wekker op lokale tijd zetten.
Natuurlijk kun je niet zomaar sla een lokale tijd op als u met gegevens van over de hele wereld werkt. Je moet een paar verschillende dingen bewaren:
- De lokale tijd van de terugkerende gebeurtenis, zoals "08:00"
- De tijdzone waarin de lokale tijd wordt uitgedrukt, zoals 'America/New_York'
- Het herhalingspatroon, in welk formaat dan ook dat zinvol is voor uw toepassing, zoals dagelijks, tweewekelijks of de derde donderdag van de maand, enz.
- De volgende onmiddellijke UTC-equivalent van datum en tijd, voor zover u het kunt projecteren.
- Misschien, maar niet altijd, een lijst met toekomstige UTC-datums en -tijden, geprojecteerd op een vooraf bepaalde periode in de toekomst (misschien een week, misschien 6 maanden, misschien een jaar of twee, afhankelijk van uw behoeften). li>
Voor de laatste twee moet u begrijpen dat het UTC-equivalent van een lokale datum/tijd kan veranderen als de overheid die verantwoordelijk is voor die tijdzone besluit iets te wijzigen. Aangezien er elk jaar meerdere tijdzonedatabase-updates zijn, wilt u een plan hebben om abonneren op aankondigingen van updates en uw tijdzonedatabase bijwerken regelmatig. Telkens wanneer u uw tijdzonegegevens bijwerkt, moet u de UTC-equivalente tijden van alle toekomstige gebeurtenissen opnieuw berekenen.
Het hebben van de UTC-equivalenten is belangrijk als u van plan bent een lijst met gebeurtenissen weer te geven die meer dan één tijdzone beslaan. Dat zijn de waarden die u opvraagt om die lijst samen te stellen.
Een ander punt om te overwegen is dat als een gebeurtenis is gepland voor een lokale tijd die plaatsvindt tijdens een terugvalovergang naar de zomertijd, u moet beslissen of de gebeurtenis in eerste instantie (meestal) of in tweede instantie (soms) plaatsvindt. of beide (zelden), en bouw in uw toepassing een mechanisme in om ervoor te zorgen dat de gebeurtenis niet twee keer wordt geactiveerd, tenzij u dat wilt.
Als u op zoek was naar een eenvoudig antwoord, sorry, maar dat is er niet. Het plannen van toekomstige evenementen in verschillende tijdzones is een ingewikkelde taak.
Alternatieve aanpak
Ik heb een paar mensen een techniek laten zien waarbij ze doen gebruik UTC-tijd voor planning, dat wil zeggen dat ze een startdatum in lokale tijd kiezen, die converteren naar UTC om te worden opgeslagen en ook de tijdzone-ID opslaan. Vervolgens passen ze tijdens runtime de tijdzone toe om de oorspronkelijke UTC-tijd terug te zetten naar de lokale tijd, en gebruiken die lokale tijd vervolgens om de andere herhalingen te berekenen, alsof het degene was die oorspronkelijk was opgeslagen zoals hierboven.
Hoewel deze techniek werkt , de nadelen zijn:
-
Als er een tijdzone-update is die de lokale tijd wijzigt voordat de eerste instantie wordt uitgevoerd, wordt het hele schema verstoord. Dit kan worden verholpen door een tijd in het verleden te kiezen voor de "eerste" instantie, zodat de tweede instantie ook echt de eerste is.
-
Als de tijd echt een "zwevende tijd" is die de gebruiker zou moeten volgen (zoals in een wekker op een mobiele telefoon), moet u nog steeds tijdzone-informatie opslaan voor de zone waarin deze oorspronkelijk is gemaakt - zelfs als dat is niet de zone waarin je wilt rennen.
-
Het voegt extra complexiteit toe zonder enig voordeel. Ik zou deze techniek reserveren voor situaties waarin je misschien een UTC-planner hebt gehad waarin je de ondersteuning voor tijdzones achteraf probeert in te bouwen.