Först, vänligen inse att i modern terminologi bör du säga UTC istället för GMT. De är för det mesta likvärdiga, förutom att UTC är mer exakt definierat. Reservera termen GMT för att hänvisa till den del av tidszonen i Storbritannien som är i kraft under vintermånaderna med offset UTC+0.
Nu till din fråga. UTC är inte nödvändigtvis det bästa sättet att lagra alla datum- och tidsvärden. Det fungerar särskilt bra för tidigare evenemang, eller för framtida absolut evenemang, men det fungerar inte så bra för framtida lokala händelser – särskilt framtida återkommande händelser.
Jag skrev om detta på ett annat svar nyligen, och är ett av få undantagsfall där lokal tid är mer vettigt än UTC. Huvudargumentet är "väckarklocksproblemet". Om du ställer in väckarklockan på UTC kommer du att vakna en timme för tidigt eller sent på dagen för sommartid. Det är därför de flesta ställer in sina väckarklockor efter lokal tid.
Naturligtvis kan du inte bara lagra en lokal tid om du arbetar med data från hela världen. Du bör lagra några olika saker:
- Den lokala tiden för den återkommande händelsen, till exempel "08:00"
- Tidszonen som den lokala tiden uttrycks i, till exempel "America/New_York"
- Återkommande mönstret, oavsett vilket format som är meningsfullt för din ansökan, till exempel dagligen, varannan vecka eller den tredje torsdagen i månaden osv.
- Nästa omedelbart UTC-datum och tidsekvivalenter, så gott du kan projicera det.
- Kanske, men inte alltid, en lista över framtida UTC-datum och tider för händelser, projicerade en fördefinierad period in i framtiden (kanske en vecka, kanske 6 månader, kanske ett år eller två, beroende på dina behov).
För de två sista, förstå att UTC-motsvarigheten till alla lokala datum/tider kan ändras om regeringen som är ansvarig för den tidszonen beslutar att ändra något. Eftersom det finns flera tidszondatabasuppdateringar varje år, vill du ha en plan för att prenumerera på meddelanden om uppdateringar och uppdatera din tidszondatabas regelbundet. När du uppdaterar din tidszonsdata måste du räkna om UTC-ekvivalenta tider för alla framtida händelser.
Att ha UTC-motsvarigheterna är viktigt om du planerar att visa någon form av lista över händelser som spänner över mer än en tidszon. Det är de värden du kommer att fråga för att skapa den listan.
En annan punkt att tänka på är att om en händelse är schemalagd för en lokal tid som inträffar under en återgångsövergång till sommartid, måste du bestämma om händelsen inträffar i den första instansen (vanligtvis) eller den andra instansen (ibland), eller båda (sällan), och bygg in en mekanism i din applikation för att säkerställa att händelsen inte aktiveras två gånger om du inte vill.
Om du letade efter ett enkelt svar - förlåt, men det finns inget. Att schemalägga framtida händelser över tidszoner är en komplicerad uppgift.
Alternativ metod
Jag har fått några personer att visa mig en teknik där de gör använd UTC-tid för schemaläggning, vilket är att de väljer ett startdatum i lokal tid, konverterar det till UTC som ska lagras och lagrar även tidszons-ID. Sedan vid körning tillämpar de tidszonen för att konvertera den ursprungliga UTC-tiden tillbaka till lokal tid, och använder sedan den lokala tiden för att beräkna de andra upprepningarna, som om det vore den som ursprungligen lagrades enligt ovan.
Även om den här tekniken fungerar , nackdelarna är:
-
Om det finns en tidszonsuppdatering som ändrar den lokala tiden innan den första instansen körs, kommer det att kasta bort hela schemat. Detta kan mildras genom att välja en tidpunkt i det förflutna för den "första" instansen, så att den andra instansen verkligen är den första.
-
Om tiden verkligen är en "flytande tid" som borde följa användaren runt (som i en väckarklocka på en mobiltelefon), måste du fortfarande lagra tidszonsinformation för den zon den ursprungligen skapades i - även om det är inte den zon du vill springa i.
-
Det tillför ytterligare komplexitet utan någon fördel. Jag skulle reservera den här tekniken för situationer där du kan ha haft en UTC-endast schemaläggare som du försöker anpassa tidszonstödet till.