Bitte beachten Sie zunächst, dass Sie in der modernen Terminologie UTC anstelle von GMT sagen sollten. Sie sind größtenteils gleichwertig, außer dass UTC genauer definiert ist. Reservieren Sie den Begriff GMT, um sich auf den Teil der Zeitzone im Vereinigten Königreich zu beziehen, der während der Wintermonate mit dem Offset UTC+0 gilt.
Nun zu deiner Frage. UTC ist nicht unbedingt die beste Methode zum Speichern aller Datums- und Uhrzeitwerte. Es funktioniert besonders gut für Vergangenheit Ereignisse oder für zukünftige absolute Veranstaltungen, aber es funktioniert nicht so gut für zukünftige lokale Ereignisse - insbesondere zukünftige wiederkehrende Veranstaltungen.
Ich habe darüber auf einer anderen Antwort geschrieben kürzlich und ist einer der wenigen Ausnahmefälle, in denen die lokale Zeit sinnvoller ist als die UTC. Hauptargument ist das „Wecker-Problem“. Wenn Sie Ihren Wecker auf UTC stellen, wachen Sie am Tag des Übergangs zur Sommerzeit eine Stunde früher oder später auf. Aus diesem Grund stellen die meisten Leute ihre Wecker auf die Ortszeit.
Natürlich können Sie nicht einfach Speichern Sie eine Ortszeit, wenn Sie mit Daten aus der ganzen Welt arbeiten. Sie sollten ein paar verschiedene Dinge speichern:
- Die Ortszeit des wiederkehrenden Ereignisses, z. B. "08:00"
- Die Zeitzone, in der die Ortszeit ausgedrückt wird, z. B. "Amerika/New_York"
- Das Wiederholungsmuster in einem beliebigen Format, das für Ihre Anwendung sinnvoll ist, z. B. täglich, zweiwöchentlich oder am dritten Donnerstag im Monat usw.
- Die nächste sofort Äquivalent zu UTC-Datum und -Zeit, so gut Sie es projizieren können.
- Vielleicht, aber nicht immer, eine Liste zukünftiger UTC-Datums- und Zeitangaben, projiziert auf einen vordefinierten Zeitraum in die Zukunft (vielleicht eine Woche, vielleicht 6 Monate, vielleicht ein oder zwei Jahre, je nach Bedarf).
Beachten Sie bei den letzten beiden, dass sich das UTC-Äquivalent eines lokalen Datums / einer lokalen Uhrzeit ändern kann, wenn die für diese Zeitzone zuständige Regierung beschließt, etwas zu ändern. Da es jedes Jahr mehrere Aktualisierungen der Zeitzonendatenbank gibt, sollten Sie einen Plan für haben abonnieren Sie Ankündigungen von Updates und aktualisieren Sie Ihre Zeitzonendatenbank regelmäßig. Immer wenn Sie Ihre Zeitzonendaten aktualisieren, müssen Sie die UTC-Äquivalentzeiten aller zukünftigen Ereignisse neu berechnen.
Die UTC-Äquivalente sind wichtig, wenn Sie vorhaben, eine beliebige Liste von Ereignissen anzuzeigen, die sich über mehr als eine Zeitzone erstrecken. Das sind die Werte, die Sie abfragen, um diese Liste zu erstellen.
Ein weiterer zu berücksichtigender Punkt ist, dass Sie entscheiden müssen, ob das Ereignis in der ersten Instanz (normalerweise) oder in der zweiten Instanz (manchmal) auftritt, wenn ein Ereignis für eine Ortszeit geplant ist, die während eines DST-Fallback-Übergangs auftritt. oder beides (selten) und bauen Sie einen Mechanismus in Ihre Anwendung ein, um sicherzustellen, dass das Ereignis nicht zweimal ausgelöst wird, es sei denn, Sie möchten es.
Wenn Sie nach einer einfachen Antwort gesucht haben - tut mir leid, aber es gibt keine. Das Planen zukünftiger Ereignisse über Zeitzonen hinweg ist eine komplizierte Aufgabe.
Alternativer Ansatz
Einige Leute haben mir eine Technik gezeigt, bei der sie es tun UTC-Zeit für die Planung verwenden, d. h., sie wählen ein Startdatum in Ortszeit aus, konvertieren dieses in UTC, um es zu speichern, und speichern auch die Zeitzonen-ID. Dann wenden sie zur Laufzeit die Zeitzone an, um die ursprüngliche UTC-Zeit zurück in die Ortszeit zu konvertieren, und verwenden dann diese Ortszeit, um die anderen Wiederholungen zu berechnen, als ob es die ursprünglich wie oben gespeicherte wäre.
Diese Technik wird funktionieren , die Nachteile sind:
-
Wenn es eine Zeitzonenaktualisierung gibt, die die Ortszeit ändert, bevor die erste Instanz ausgeführt wird, wird der gesamte Zeitplan durcheinander gebracht. Dies kann abgemildert werden, indem für die "erste" Instanz ein Zeitpunkt in der Vergangenheit gewählt wird, sodass die zweite Instanz wirklich die erste ist.
-
Wenn die Zeit wirklich eine "schwebende Zeit" ist, die dem Benutzer folgen soll (z. B. in einem Wecker auf einem Mobiltelefon), müssen Sie immer noch Zeitzoneninformationen für die Zone speichern, in der sie ursprünglich erstellt wurde - selbst wenn das ist nicht die Zone, in der Sie laufen möchten.
-
Es fügt zusätzliche Komplexität ohne Nutzen hinzu. Ich würde diese Technik für Situationen reservieren, in denen Sie vielleicht einen UTC-Scheduler hatten, in dem Sie versuchen, die Zeitzonenunterstützung nachzurüsten.
