Scheduling & DST

Question

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 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 Timing wichtig.

Answer 1

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 (im letzten Jahr geschah dies in den USA) und die Ereignisse verschieben sich dann in GMT, aber nicht in Ortszeit.

Dann, wenn Sie benachrichtigt werden müssen, wenn das Ereignis auftritt, jeden Tag sammeln Sie die Ereignisse für die nächsten 24-48 Stunden und konvertieren Sie ihre Zeiten in GMT dann. Dazu benötigen Sie eine Standort-Zeitzone-Datenbank wie this one. 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.

Answer 2

Ich denke, dass Sie mit GMT (UTC) auf dem richtigen Weg sind. Verwenden Sie UTC als Ihre kanonische Zeitstempel-Darstellung, wenn Sie ein Ereignis haben, das bei einem bestimmten Zeitpunkt auftritt (oder aufgetreten ist). UTC ist von DST-Regeln nicht betroffen und dient daher als eine großartige, eindeutige Point-in-Time-Repräsentation.

Sobald Sie eine Strategie für eine eindeutige Darstellung des Ereignisses Datum/Zeit haben, dann können Sie ziemlich leicht lösen das Problem der lokalisierende Datum/Zeit basierend auf welcher Zeitzone ist am sinnvollsten von Ihren Benutzern zu akzeptieren (oder zu ihnen anzeigen). 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 DB 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 bestimmte Bereichsänderung.

Es ist nicht das einfachste Problem in der Welt und stinkt, dass wir es tun müssen, aber sobald Sie es ein paar Mal getan haben und die Trennung der Bedenken zwischen speichern genaue Punkt-in-Zeit-Darstellung vs. die Sorge der Lokalisierung, dann wird es zur zweiten Natur.

Answer 3

Warum nicht die Verantwortung an die Benutzer weitergeben. Ich nehme an, dass sie registriert sein müssen, um die Anwendung zu verwenden.

Lassen Sie sie einfach in ihrem Profil sagen, was ihre Zeitverschiebung ist.Wie GMT + 2, GMT-8, usw. Sie würden wissen, wenn ihre DST-Einstellungen geändert und ihr Profil entsprechend aktualisiert.

Dies hängt natürlich von Ihrer Benutzerbasis ab. Sie können den Ansatz akzeptieren oder nicht.