Best Practices beim Erstellen von Anwendungen mit Zeitzone

Question

Ich entwickle eine webbasierte Zeitzonen-App, und ich bin auf der Suche nach Best Practices dafür.

Zum Beispiel habe ich Benutzer A und Benutzer B, die Zeitzone festgelegt haben. Benutzer A gibt eine Zeit ein. (in seiner Zeitzone.) Wie speicherst du das in der DB?

• [Option 1] Original Zeit mit Original-Zeitzone
• [Option 2] UCT Zeit in UCT gespeichert.

Use Cases sind

• Benutzer A dieses Mal gezeigt werden muss.
• Benutzer B muss dieses Mal angezeigt werden.
• Anon Benutzer muss diesmal angezeigt werden.
• Zeitzonenunterschiede müssen berechnet werden.

Ich kann die Vorteile beider Möglichkeiten sehen. Ich suche nicht speziell nach einer Antwort auf diese Frage, sondern nach Informationen über den Aufbau von Timezone-bewussten Web-Apps im Besonderen.

Ich benutze Python, aber auf der Suche nach Sprache agnostischen Tipps auch.

Answer 1

Im Allgemeinen denke ich, dass es sinnvoller ist, Zeiten in das gemeinsame Format (UTC) zu konvertieren, um sie zu speichern und sie dann in die eigene Zeitzone des Benutzers umzuwandeln, wenn sie angezeigt werden. Sie können möglicherweise anhand Ihrer IP-Adresse nach anonymen Benutzern oder einer bestimmten Zeitzone suchen.

Natürlich hängt es davon ab, was Sie tun. Für viele Dinge ist die absolute Zeit wichtig: z.B. Wenn es eine Videokonferenz gibt, muss die Startzeit für Personen in jeder Zeitzone gleich sein. Aber es gibt ein paar Fälle, in denen etwas nach lokaler Zeit gemacht wird. Earth Hour zum Beispiel ist von 8.30 bis 9.30 Uhr in jeder Zeitzone.

Answer 2

Semantisch sind fast alle Datumsangaben, die Sie manipulieren, absolute Zeiten (zum Beispiel: Abrechnung, Kreationen und Modifikationen, zuletzt gesehen, api-Drosseln, SO-Bounties ...). Sie sollten in UTC gespeichert werden, damit keine Unklarheit darüber besteht. Andernfalls, wenn eine Regierung eine DST-Regel ändert und Ihre Systemregeln aktualisiert werden, ändert sich der von Ihnen gespeicherte Wert.

Wenn sich datetime auch auf eine Zeit und einen Ort bezieht (z. B. ein Meeting, Kalender allgemein), können Sie das vollständige symbolische Datum in RFC 3339 speichern, einschließlich eines Zeitzonennamens (nicht identisch mit einem UTC-Offset). und konvertieren auf UTC on demand.