Først skal du erkende, at du i moderne terminologi bør sige UTC i stedet for GMT. De er for det meste ækvivalente, bortset fra at UTC er mere præcist defineret. Reserver udtrykket GMT for at henvise til den del af tidszonen i Storbritannien, der er gældende i vintermånederne med offset UTC+0.
Nu til dit spørgsmål. UTC er ikke nødvendigvis den bedste måde at gemme alle dato- og tidsværdier på. Det fungerer særligt godt for tidligere begivenheder eller til fremtidige absolutte begivenheder, men det fungerer ikke så godt for fremtidige lokale begivenheder - især fremtidige tilbagevendende begivenheder.
Jeg skrev om dette om et andet svar for nylig, og er et af de få undtagelsestilfælde, hvor lokal tid giver mere mening end UTC. Hovedargumentet er "vækkeurproblemet". Hvis du indstiller dit vækkeur til UTC, vil du vågne en time for tidligt eller sent på dagen for sommertidsovergangene. Det er derfor, de fleste mennesker indstiller deres vækkeure efter lokal tid.
Selvfølgelig kan du ikke bare gem en lokal tid, hvis du arbejder med data fra hele verden. Du bør gemme et par forskellige ting:
- Den lokale tid for den tilbagevendende begivenhed, f.eks. "08:00"
- Den tidszone, som den lokale tid er udtrykt i, f.eks. "America/New_York"
- Gentagelsesmønsteret, uanset hvilket format der giver mening for din ansøgning, f.eks. dagligt, ugentligt eller den tredje torsdag i måneden osv.
- Den næste umiddelbare UTC-dato og -tidsækvivalent, så godt du kan projicere det.
- Måske, men ikke altid, en liste over UTC-dato og -tidspunkter for fremtidige begivenheder, der er projiceret en foruddefineret periode ud i fremtiden (måske en uge, måske 6 måneder, måske et år eller to, afhængigt af dine behov).
For de sidste to skal du forstå, at UTC-ækvivalenten til enhver lokal dato/tid kan ændre sig, hvis den regering, der er ansvarlig for den tidszone, beslutter at ændre noget. Da der er flere tidszonedatabaseopdateringer hvert år, vil du gerne have en plan for at abonnere på meddelelser om opdateringer og opdater din tidszonedatabase regelmæssigt. Hver gang du opdaterer dine tidszonedata, skal du genberegne UTC-ækvivalenttider for alle fremtidige begivenheder.
Det er vigtigt at have UTC-ækvivalenter, hvis du planlægger at vise en hvilken som helst liste over begivenheder, der spænder over mere end én tidszone. Det er de værdier, du vil forespørge på for at bygge den liste.
Et andet punkt at overveje, er, at hvis en hændelse er planlagt til en lokal tid, der opstår under en sommertid, skal du beslutte, om hændelsen finder sted i den første instans (normalt) eller den anden instans (nogle gange), eller begge dele (sjældent), og indbygg en mekanisme i din applikation for at sikre, at begivenheden ikke udløses to gange, medmindre du ønsker det.
Hvis du ledte efter et simpelt svar - undskyld, men der er ikke et. At planlægge fremtidige begivenheder på tværs af tidszoner er en kompliceret opgave.
Alternativ tilgang
Jeg har haft nogle få mennesker til at vise mig en teknik, hvor de gør bruge UTC-tid til planlægning, hvilket er, at de vælger en startdato i lokal tid, konverterer den til UTC, der skal gemmes, og gemmer også tidszone-id'et. Så ved kørsel anvender de tidszonen til at konvertere den oprindelige UTC-tid tilbage til lokal tid, og bruger derefter den lokale tid til at beregne de andre gentagelser, som om det var den, der oprindeligt var gemt som ovenfor.
Selvom denne teknik vil virke , ulemperne er:
-
Hvis der er en tidszoneopdatering, der ændrer den lokale tid, før den første forekomst køres, vil den kaste hele tidsplanen af. Dette kan afbødes ved at vælge et tidligere tidspunkt for den "første" instans, således at den anden instans virkelig er den første.
-
Hvis tiden virkelig er en "flydende tid", der burde følge brugeren rundt (såsom i et vækkeur på en mobiltelefon), ville du stadig skulle gemme tidszoneoplysninger for den zone, den oprindeligt blev oprettet i - også selvom det er ikke den zone, du vil løbe i.
-
Det tilføjer yderligere kompleksitet uden nogen fordel. Jeg vil reservere denne teknik til situationer, hvor du måske har haft en UTC-only planlægger, som du forsøger at eftermontere tidszonesupport til.