Handling von Zeitzonen im Speicher?

StackOverflow https://stackoverflow.com/questions/11975

Frage

Speichern alles in GMT?

Speichern Sie alles so, wie es eingegeben wurde, mit einem embedded-offset?

Die Mathematik zu tun, jedes mal, wenn du gerendert?

Anzeige der relativen Zeiten "1 Minute ago"?

War es hilfreich?

Lösung

Sie haben zu lagern im UTC-Format - wenn Sie nicht, Ihre historischen Berichterstattung und Verhalten während Dinge wie die Sommerzeit geht...lustig.GMT ist eine lokale Zeit, unter Tageslicht-Einsparungen relativ zu UTC (das ist nicht).

Präsentation für Benutzer in verschiedenen Zeitzonen kann ein echter bastard wenn Sie die Speicherung von lokalen Zeit.Es ist einfach zu justieren, um die lokale, wenn Ihre raw-Daten in UTC - fügen Sie einfach Ihre Benutzer-offset-und Sie sind fertig!

Joel Sprach darüber in einem der podcasts (in einer Runde über Art und Weise) - er sagte zu speichern Sie Ihre Daten in der höchstmöglichen Auflösung (suchen Sie nach 'treue'), da kann man immer munge, wenn es geht wieder raus.Das ist, warum ich sagen, speichern Sie es als UTC-Zeit, die als lokale Zeit, die Sie brauchen, um anpassen für alle, die nicht in dieser Zeitzone, und das ist eine Menge harte Arbeit.Und Sie brauchen, um zu speichern, ob zum Beispiel die Sommerzeit war wirksam, wenn Sie gespeichert werden, ist die Zeit.Yuk.

Häufig in Datenbanken habe ich in der Vergangenheit gespeichert, die zwei - UTC für die Sortierung, lokalen Zeit display.Diese Weise weder der Benutzer noch der computer verwirrt.

Nun, wie angezeigt:Sicher, Sie können tun die "3 minutes ago" Sache, aber nur, wenn Sie speichern UTC - ansonsten eingegebene Daten in verschiedenen Zeitzonen wird, zu tun Sachen wie Anzeige als "-4 Stunden", die flippen die Menschen aus.Wenn Sie gehen, um display eine tatsächliche Zeit, die Menschen lieben, um es in Ihrer lokalen Zeit - und wenn Daten eingegeben werden, die in mehreren Zeitzonen können Sie nur tun, dass Sie mit Leichtigkeit wenn Sie das speichern UTC.

Andere Tipps

Die Antwort ist, wie immer, wird "hängt".

Es hängt davon ab, was Sie beschreiben, mit der Zeit, und wie die Daten Ihnen zur Verfügung gestellt wurde.Der Schlüssel zu der Entscheidung, wie Sie Zeit speichern der Werte wird die Entscheidung, wenn Sie Informationen zu verlieren, indem Sie die Zeitzone, sowie nicht verwunderlich Ihre Benutzer.

Es gibt bestimmte Vorteile bei der Speicherung von Daten in UTC time_t - es ist ein einzelnes int, ermöglicht schnelle Sortierung und einfache Lagerung.

Ich sehe das problem als aufgegliedert in die Bereiche:

  1. Historische Daten
  2. Zukunft, Kurzfristig Daten
  3. Zukünftige, Langfristige Daten

Mit dem folgenden Unterklassen auf jeden:

  1. - System Zur Verfügung Gestellt
  2. Benutzer

Betrachten wir Sie nacheinander.

- System Zur Verfügung Gestellt:Ich würde empfehlen, running-Systeme in UTC, dann vermeiden Sie die Zeitzone problem und wieder, dass keine Informationen verloren gehen, ist, zu sehen (es ist immer UTC).

Historische Daten:Dies sind Dinge wie system-log-Dateien, Prozess-Statistiken, tracing, Kommentar, Datum/Uhrzeit, etc.Den Daten ist nicht zu ändern, und die Zeitzone Deskriptor ist nicht zu ändern, auch rückwirkend.Für diese Art von Daten es besteht keine Informationen verloren durch die Speicherung der Daten in UTC unabhängig von der Zeitzone, es war in.Also, legen Sie die Zeitzone.

Zukünftige, Langfristige Daten:Dies sind Ereignisse, die entweder weit genug in der Zukunft, oder wird immer wieder vor.Wenn Sie gehalten werden, um lange genug, timezone-Deskriptoren sind garantiert ändern.Ein gutes Beispiel dieser Art von Daten ist, "Die Wöchentlichen Management-Meetings".Dies sind die Daten, die einmal eingegeben, und erwartet, dass Sie arbeiten in alle Ewigkeit.Für diese Werte ist es wichtig zu bestimmen, ob es system-oder Benutzer zur Verfügung gestellt.Für vom Benutzer bereitgestellte Daten die Zeit, die gespeichert werden soll, mit der der Schöpfer die Zeitzone, alles andere resultiert in dem Verlust der Informationen.Diese Informationen verloren gehen, wird deutlich, wenn das timezone-definition ändert und die Zeit angezeigt, zu der Schöpfer als eine ganz andere Wert!

Als Bwooce angedeutet hat, es gibt einige Verwirrung, in dem der Schöpfer und Zuschauer sind in verschiedenen Zeitzonen.In diesem Fall würde ich erwarten, dass die Anwendung, um anzuzeigen, welche Zeit-Werte verschoben haben, die wegen eines Zeitzone Wechsel von Ihren bisherigen Standorten.

Zukunft, Kurzfristig Daten:Dies sind die Daten, die schon bald zu historischen oder ist nur für eine kurze Zeit.Beispiele könnten sein, Intervall-Timer, rating übergänge, etc.Für diese Daten, da die Wahrscheinlichkeit gering ist, dass die definition ändert sich zwischen die Schöpfung, den Wert und die Zeit wird es historisch ist, könnte es möglich sein, den Weg mit fallen der Zeitzone.Ich habe jedoch festgestellt, dass diese Werte haben die schlechte Angewohnheit, zu "Zukünftigen, langfristigen Daten".

Sobald Sie sich entschieden haben, speichern Sie die Zeitzone, muss darauf geachtet werden, wie es gespeichert ist.

  • Nicht speichern Sie die Zeitzone als offset-oder die full-Deskriptor.

Wenn Sie speichern einer Zeitzone als offset, was tun Sie, wenn sich die Zeitzone ändert?Gehen Sie durch das system und machen Sie eine Decke Wechsel auf die bestehenden Daten?Wenn Sie dies tun, haben Sie jetzt jede historische Werte falsch.Gute Beispiele für diese Fehler sind Oracle und iCal.Oracle speichert Zeitzone als offset von der UTC und iCal enthält die vollständige Beschreibung für die Erstellung Zeitzone.

  • Speichern Sie es als einen Namen.

Dies ermöglicht die definition der Zeitzone zu ändern, ohne ändern Sie die vorhandenen Werte, die Sie haben.Es macht die Sortierung erschwert, da jeder index, der generiert wird, ist möglicherweise ungültig, wenn der Zeitzone und änderung der Daten.

Wenn Entwickler weiterhin speichern alles in UTC-Zeit, unabhängig von der Zeitzone, werden wir weiterhin sehen die Probleme, die wir gesehen haben, mit der letzten charge der Zeitzone änderungen.

Bei einer organisation, die Sekretärinnen mussten drucken Sie die Kalender für Ihre teams, bevor die Sommerzeit Datum, und dann drucken Sie Sie erneut, nachdem Sie die änderung.Schließlich verglichen Sie die beiden und neu erstellt, alle Termine, die verschoben hatte.Natürlich, Sie mehrfach vergessen, und es gab mehrere Wochen Schmerzen, bis der alte Sommerzeit-Datum erreicht wurde, und die Zeit wurde wieder richtig.

Josh ist völlig richtig vor, aber ich habe eine subtile VORBEHALT zu erklären.Dies ist ein Fall, mit keine richtige Antwort hinsichtlich zukünftiger Ereignisse und Zeitzonen.

Betrachten Sie den Fall eines sich wiederholenden Termin.Er tritt in GMT-0000 (der Einfachheit halber), die ist 1200 NZST (New Zealand Standard Time) und 1000 AEST in Sydney Australien.

Wenn die Sommerzeit in Kraft tritt, in einer zone, was kommen sollte zu dem Termin?Sollte es:

1a.Wenn die TZ-änderung ist in der zone der der Termin ist "Eigentümer" (die es gebucht) dann versuchen, um zu bleiben den gleichen Schreibtisch Uhrzeit (z.B. 10:00 Uhr)?
1b.Wenn die TZ ändern, ist in einer der anderen meeting-Teilnehmer Zonen dann nicht ändern

Folgen:Es bewegt sich für alle anderen, unerwartet, durch die Besitzer TZ ändern, aber es bleibt "die 10 treffen" so weit wie die Besitzer ist besorgt.

'2.Wie oben, aber Umgekehrt.

Folgen:Es bewegt wird, für die meeting-Eigentümer (das 10am Sitzung wird die 9am meeting -, oder v/v), was erwartet werden kann, dass aber unbequem.Es bleibt bei den gleichen Schreibtisch, Uhr, Zeit für die anderen Teilnehmer, bis Sie durch Ihre eigenen TZ übergang.

Weder ist perfekt.Betrachten wir den Fall von zwei Terminen, Buchung von der Person A, die Auftritt, um 10 Uhr morgens Ortszeit, die andere gebucht, die von Person B mit Person A, die als ein Teilnehmer Auftritt um 9 Uhr.Wenn Person A und Person B sind in unterschiedlichen TZ dann eine Zeitumstellung könnte leicht dazu führen, dass Sie sich doppelt gebucht.

Wenn Ihre Meinung ist ein bisschen gebogen an diesem Punkt verstehe ich durchaus.

Der Punkt hinter diesem Beispiel ist, dass zu tun, entweder von diesen Verhaltensweisen richtig Sie müssen nicht nur wissen, UTC-Ausgabe der lokalen Zeit, sondern der TZ (und nicht offset), dass der Besitzer war, als Sie es gebucht.Andernfalls haben Sie keine andere Wahl, als option 2, schweigend, ohne auch nur die Information, dass jemand die Dinge haben sich geändert, seit GMT-Zeiten ändern sich nicht, und nur die Darstellung ändert sich...richtig?(Nein, das ist die Falle, die Präsentation ankommt, wenn Sie Ihre 10 Uhr treffen bewegt sich)

Ich habe Kredit-mein Kollege und Freund Jason Pollock für diese Einsicht.Lesen seiner Ansicht hier, und das follow-up zu diskutieren iCal und VTIMEZONE hier.

Speichern alles in GMT/UTC scheint mir am logischsten.Sie können dann das Datum und die Zeit in jeder Zeitzone, die Sie wollen.

Ein paar ceveats:

  1. Wenn eine Zeit nur, angegeben Wanduhr Zeit, und das ist die führende Darstellung, dann ist es nicht absolut angegeben Zeit.Sie sollte (und kann) umwandeln in jedem GMT Darstellung.E. G.9:00 BIN jeden morgen.In anderen Worten:dies ist keine (Datum)Zeit.
  2. Wenn Sie speichern Sie ein Datum und die Zeit der Zukunft Termin, sollten Sie die offset zur GMT angegeben durch die Eingabe Zeitzone und der der moment in der Zeit selbst.Also, wenn es einen Termin im Sommer machte im winter z.B.Westeuropa ist es +2:00, obwohl die normal - (winter-Zeit) offset +1:00.Diese lösen die Kalender problem, dass Bwooce erwähnt.
  3. Natürlich, die gleiche das gilt mit der rechten offset während der Konvertierung GMT gilt bei der Umwandlung zurück in ein Datum und Uhrzeit in einer bestimmten Zeitzone.

Zum Glück, wenn es richtig eingesetzt wird, der (.NET) - DateTime-Typ kümmert sich um all die blutigen details, halten, Kalender usw.für Sie und all dies sollte sehr einfach sein, wenn Sie wissen, wie es funktioniert.

Ich persönlich kann nicht sehen, jeder Grund, nicht zu Shop alles, was in GMT, und dann verwenden die Benutzer lokale Zeitzone, um die Zeit anzuzeigen, wie es sich auf Sie bezieht.

Wenn Sie wollen display die relative Zeit, die Sie offensichtlich müssen noch die Zeit und machen Sie eine übersetzung, aber wenn Sie wollen, zu tun die übersetzung ich denke, dass GMT immer noch Ihre beste option.

Also lief ich ein kleines experiment mit MSSQL-server.

Ich habe eine Tabelle erstellt und fügte eine Zeile mit der aktuellen lokalisiert Zeitzone (Australien).Dann änderte ich meine datetime zu werden GMT und fügte eine weitere Zeile.

Auch wenn diese Zeilen wurden Hinzugefügt etwa 10 Sekunden auseinander, erscheinen Sie in der SQL server als tho, sind Sie 10 Stunden auseinander.

Wenn nichts anderes, so wenigstens sagt mir, ich sollte die Speicherung von Daten in einem conisitent Art und Weise, die für mich, fügt Gewicht auf das argument für die Speicherung Ihnen als GMT.

MS Dynamics speichert GMT und dann auf user-Ebene kennt Ihre Zeiten zone relative to GMT.Zeigt dann Elemente, um Sie in Ihrer Zeitzone.

Dachte nur, ich würde werfen, dass da draußen das ist eine ziemlich große Gruppe auf MS-und dies ist, wie Sie beschlossen, es zu handhaben.

ich bevorzuge, um alles zu speichern, die mit der Zeitzone.der Kunde kann entscheiden, welcher Weg es sein soll später präsentiert.meine Lieblings-Bibliothek für die Konvertierung ist die PostgreSQL-Datenbank.

Schauen Sie hier, das w3c haben einen hervorragenden job gemacht Beantwortung der Frage.

Bei den Anwendungsbeispielen.

http://www.w3.org/TR/timezone/

Beachten Sie, dass Sie empfehlen die Aufbewahrung datetimes als UTC nicht, GMT, GMT unterliegt Sommerzeit.

Ich mag die Speicherung in GMT und zeigen nur relative ("10 Sekunden vor", "vor 5 Monaten").- Benutzer nicht brauchen, um zu sehen, tatsächliche Zeitstempel für die meisten Anwendungsfälle.

Es gibt sicherlich auch Ausnahmen, und eine einzelne Anwendung möglicherweise haben viele von Ihnen, so es kann nicht sein 'one-true-way" - Antwort.Dinge, die brauchen starke audit-Fähigkeit (z.B.Wahlen), und Systeme, wo die Zeit ist Teil der Domäne des Diskurses (Astronomie, der wissenschaftlichen Forschung) könnte die Nachfrage true Zeitstempel um zu dem Benutzer angezeigt werden.

Die meisten apps sind jedoch leichter zu verstehen, mit einem einfachen relativen Zeit.

Ich in der Regel nur mit einer Unix-Zeit.nicht unbedingt in der Zukunft sicher ist, aber es funktioniert ziemlich gut.

Immer Speicher in GMT (oder UTC).Von dort ist es leicht zu konvertieren, um eine local time zone-Wert.

Termine gespeichert werden sollen UTC, es sei denn, es wird vom Benutzer bereitgestellten Daten und Sie können NICHT wissen, welche Zeitzone der Benutzer bestimmt, die Daten werden in.Manchmal (sehr selten), müssen Sie nur speichern Sie die Stunde, minute, Sekunde, Tag, Monat und Jahr-Komponenten ohne Zeitzone, so dass Sie spucken es zurück an den Benutzer.Jetzt für Entwickler, oder wenn Sie sich nicht sicher sind, speichern UTC und Sie werden zu 99% korrekt.

Aber lassen Sie sich nicht täuschen, indem Sie glauben, das funktioniert 100% der Zeit, die für alle Fälle die ganze Zeit.Tut es nicht.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top