Ich schreibe eine Kalender / Scheduling-App in PHP. Im Moment nehme ich den Wochentag, an dem das Ereignis stattfinden soll, und die Uhrzeit. Ich frage auch nach der Zeitzone und stelle mich entsprechend ein, um die Ereigniszeit in GMT zu erhalten.
Dann speichere ich diese Zeit als einen Offset von Mitternacht des Tages der Show. Das ist in Ordnung und funktioniert gut, aber was passiert, wenn ich die Sommerzeit erreiche? Ich bin mir nicht sicher, was ich tun soll, wenn das passiert. Das andere Problem ist, dass nicht alle Länder DST haben, also bin ich dort irgendwie in der Klemme.
Ich zeige diese Ereignisse in einem Kalender an, also ist das Timing wichtig.
Der Umgang mit DST ist ein echter Schmerz.
Bei zukünftigen Ereignissen sollten Sie den Ort und die Ortszeit speichern, zu der das Ereignis stattfinden soll, nicht die GMT-Zeit. Dies liegt daran, dass sich Regierungen manchmal ändern, wenn die Sommerzeit beginnt und endet (das ist erst letztes Jahr in den USA passiert) und die Ereignisse verschieben sich dann in GMT, aber nicht in Ortszeit.
Dann, wenn Sie benachrichtigt werden müssen, wenn das Ereignis eintritt, sammeln Sie jeden Tag die Ereignisse für die nächsten 24-48 Stunden und konvertieren Sie ihre Zeiten dann in GMT. Um dies zu tun, benötigen Sie eine Standort-Zeitzone-Datenbank wie diese . Holen Sie den GMT-Offset für jeden Ort zum Zeitpunkt des Ereignisses und verwenden Sie diesen, um die Zeit in GMT zu konvertieren, dann wissen Sie genau, wann das Ereignis eintreten wird.
Ich denke, mit GMT (UTC) sind Sie auf dem richtigen Weg. Verwenden Sie UTC als kanonische Zeitstempeldarstellung, wenn Sie ein Ereignis haben, das zu einem bestimmten Zeitpunkt auftritt (oder stattgefunden hat). UTC ist von DST-Regeln nicht betroffen und dient daher als großartige, eindeutige Point-in-Time-Darstellung.
Sobald Sie eine Strategie für die eindeutige Darstellung des Ereignisdatums / -zeitpunkts haben, können Sie das Problem des > -Datums / -Zeitpunkts ziemlich leicht lösen, basierend auf welcher Zeitzone es am sinnvollsten ist, von zu akzeptieren Ihre Benutzer (oder zeigen Sie ihnen an). Sie müssen wahrscheinlich auch die Zeitzone des Ereignisses kennen und speichern, aber da Sie das tatsächliche Ereignisdatum / die Ereigniszeit in UTC speichern, können Sie es ziemlich einfach in der Zeitzone des Benutzers lokalisieren, wenn dies relevanter ist zu ihnen in jedem gegebenen Anwendungsfall.
Diese Lokalisierung wird normalerweise mit einer Zeitzonenbibliothek durchgeführt, die entweder von Ihrem SDK bereitgestellt wird (z. B. Java hat java.util.Calendar) oder als Erweiterung eines Drittanbieters (z. B. Python hat pytz). Ich bin sicher, PHP hat ein Äquivalent, aber ich bin nicht so vertraut mit seinen Bibliotheken.
Diese Bibliotheken werden normalerweise auf einer Regeldatenbank wie der Olson Zoneinfo Datenbank aufgebaut. Diese Regeln können sich sehr häufig ändern, so dass Sie immer über Aktualisierungen der zugrunde liegenden Datenbank informiert werden müssen, insbesondere wenn Sie eine wirklich globale Anwendung entwickeln. Sie können jedoch die esoterischen, nebulösen Zeitzonenregeln externalisieren, so dass Sie die Regeldatenbank (theoretisch) aktualisieren können, ohne eine größere Aktualisierung Ihrer Laufzeitumgebung durchführen oder wichtige Codeänderungen vornehmen zu müssen, wenn die DST-Regeln in a bestimmter Bereich ändern.
Es ist nicht das einfachste Problem in der Welt und stinkt, dass wir es tun müssen, aber wenn Sie es ein paar Mal getan haben und die Trennung der Bedenken zwischen Speicherung der genauen Punkt-in-Zeit-Darstellung vs. Lokalisierung, dann wird es zur zweiten Natur.
Überlassen Sie die Verantwortung den Benutzern. Ich nehme an, dass sie registriert werden müssen, um die Anwendung zu verwenden.
Lassen Sie sie einfach in ihrem Profil sagen, wie hoch der Zeitversatz ist. Wie GMT + 2, GMT-8, usw. Sie würden wissen, wenn ihre DST-Einstellungen geändert und ihr Profil entsprechend aktualisiert.
Das hängt natürlich von Ihrer Benutzerbasis ab. Sie können den Ansatz akzeptieren oder nicht.