it-swarm.com.de

Best Practice zum Speichern von DateTime basierend auf TimeZone

Entwicklung einer Webanwendung, mit der der Benutzer einen Termin basierend auf seiner Zeitzone planen kann. Und ich speichere die vom Benutzer geplante Datumszeit als Server-Datumszeit im Datenbankfeld. Beim Anzeigen von Zeitplaninformationen wurde der Wert aus der Datenbank abgerufen und in die Benutzerzeitzone konvertiert. Verarbeitung in Codebasis Ich konvertiere die DateTime basierend auf der Benutzerzeitzone. Bitte schlagen Sie vor, ob dies die beste Vorgehensweise ist oder ob es einen einfachen Weg gibt.

19
user46506

Willkommen zu einem der schwierigsten Probleme bei der nicht rechnergestützten Programmierung - die korrekte Darstellung von Datum und Uhrzeit für Endbenutzer.

Realistisch gesehen sollten Zeitstempel in einer festen Einzeldarstellung gespeichert werden, unabhängig davon, wie sie interpretiert werden. Unabhängig davon, wie sehr Sie sich bemühen, haben Sie immer mehrdeutige Fälle, und Sie können sie nicht ohne eine feste Darstellung auflösen. Und Sie haben einen der schlimmsten Anwendungsfälle ausgewählt - einen Termin zu vereinbaren. Der einzig schlimmere häufige Anwendungsfall ist der Flugverkehr, bei dem eine Reise in einer Zeitzone beginnen und in einer anderen enden kann, was zu einer früheren Ortszeit möglich ist.

Immer, immer, IMMER in UTC speichern und in der vom Benutzer bevorzugten oder explizit angegebenen Zeitzone anzeigen. Wenn möglich, lassen Sie sich vom Benutzer mitteilen, in welcher Zeitzone er den Zeitstempel für die Eingabe hält ( zB , haben ein explizites Zeitzonenfeld und füllen es mit ihrer bevorzugten Zone vor).

35
Ross Patterson

Der einfachste Weg, mit Datums-/Uhrzeitinformationen umzugehen, hängt von den Anforderungen Ihrer Anwendung ab.

Wenn Datum und Uhrzeit vom Benutzer eingegeben werden und der Server diese Datums-/Uhrzeitinformationen nur verarbeitet, um sie in einer Datenbank zu speichern, und nicht zu erwarten ist, dass die eingegebene Uhrzeit an den Ort angepasst wird, an dem sie angezeigt wird (z. B.) Wenn der Benutzer "20:00 Uhr" eingegeben hat und diese als "20:00 Uhr" angezeigt werden soll, unabhängig davon, wo auf der Welt sie angezeigt wird. Der einfachste Weg ist, die DateTime als Ortszeit ohne Zeitzoneninformationen zu speichern.

Wenn der Server andererseits die eingegebene DateTime als Auslöser verwenden muss, um etwas zu tun, oder wenn die Zeit korrekt an die aktuelle Zeitzone angepasst werden soll, ist es am besten, die DateTime als UTC-Zeit zu speichern und auf lokal anzupassen Zeit (für den aktuellen Standort des Benutzers) jedes Mal, wenn Sie ihn aus der Datenbank lesen.

Es ist wichtig, dass Sie zwei verwandte Konzepte nicht miteinander verbinden.

Wenn Sie einen tatsächlichen Zeitpunkt manipulieren, dh eine bestimmte Zeit an einem bestimmten Tag, können Sie dies nur tun, indem Sie immer den universellen UTC-Zeitwert verwenden. Versuchen Sie niemals, dies als zeitzonenrelevanten Wert zu speichern. Wenn Sie einem Benutzer diesen Zeitwert anzeigen, konvertieren Sie zu diesem Zeitpunkt immer in die Benutzerzeitzone. (Und vergessen Sie nicht, dass sowohl die Uhrzeit als auch das Datum von der Zeitzone abhängen.)

Das andere Konzept ist das eines "Zeitausdrucks" wie "jeden Dienstag um 20:00 Uhr". Sie haben ausdrücklich erwähnt, dass Personen Termine planen können. Wenn Sie wiederkehrende Termine haben, benötigen Sie einen solchen Ausdruck. Ich kenne keine Standardausdruckssprache, aber was auch immer Sie verwenden, es wird relativ zur Zeitzone der Person sein, die es angegeben hat. Es wäre am besten, dies explizit zu machen, z. "Jeden Dienstag um 20:00 Uhr in der pazifischen Zeitzone". Im Fall eines Zeitausdrucks speichern Sie diesen immer als Zeichenfolge und verwenden niemals Systemzeitformate.

Siehe mehr Diskussion dazu in meinem Blog

2
AgilePro

Viele Antworten hier zeigen an, dass das Speichern als UTC erfolgt. Aber sei wirklich vorsichtig damit. Was passiert beispielsweise, wenn Sie einen Termin um 12:00 Uhr planen, der Termin jedoch nach der Umstellung auf Sommerzeit stattfindet? UTC speichert keine Informationen darüber, ob dst aktiv war, als der Termin gespeichert wurde. Viele große, bekannte Systeme haben diesen Fehler gemacht, bei dem ein Benutzer im Sommer um 9 Uhr morgens eine E-Mail sendet und im Winter die gesendete Zeit 8 Uhr morgens anzeigt, da die Berechnung von UTC davon abhängt, wann Sie die Uhrzeit betrachten. Nicht aktiviert, wenn die Datums-/Uhrzeitaufzeichnung aufgezeichnet wurde.

Viel besser ist es anzunehmen, dass Ihr Benutzer die Zeiten haben möchte, die er immer ausgewählt hat. Keine UTC-Konvertierung, keine Zeitkonvertierung, keine Zeitzoneninformationen, nichts. Genau das ist ein Termin von 08:00 bis 12:00 Uhr am 21. März 2016. Verwenden Sie weder die Ortszeit noch die UTC-Zeit, sondern die nicht angegebene Zeit (in json hat dies weder z noch +, in .NET hat dies DateTime.Kind = DateTimeKind.Unspecified).

Wenn Ihr Anwendungsfall darin besteht, dass Sie ein Unternehmen sind, das Besprechungen mit jemandem aus verschiedenen Zeitzonen abhält, und Sie diese Informationen beispielsweise in einem Unternehmenskalender anzeigen möchten, den Benutzern jedoch die Möglichkeit geben, die Zeit in ihrer Zeitzone anzuzeigen, ist dies der Fall wird komplizierter. Die Zeit muss für verschiedene Personen in verschiedenen Zeitzonen (Lieferant und Kunde) korrekt sein.

In diesen Fällen möchten Sie möglicherweise sogar aufzeichnen , wann der Termin in der Datenbank gespeichert wurde, in welcher Zeitzone und ob das dst beinhaltete oder nicht. Auf diese Weise können Sie die Ortszeit immer auf alles andere zurückrechnen, entweder auf das, was es jetzt sein würde oder auf das, was es historisch sein sollte. Weil Zeitzonen nicht statisch sind, was die Dinge noch komplizierter macht.

Glücklicherweise kommen hier Bibliotheken wie http://nodatime.org/ ins Spiel und werden dringend empfohlen. Sie arbeiten viel konsequenter mit Daten. Selbst dann würde ich empfehlen, alle Ihre datetime-Variablen und -Logiken in Ihre eigenen Wrapper zu packen und Schnittstellen zu verwenden, damit sie verspottet werden können, und Sie können die Logik später noch wechseln.

2
Arwin