Bewährte Methode 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 Benutzer-Zeitzone konvertiert. Verarbeitung in der Codebasis Ich konvertiere die DateTime basierend auf der Benutzer-Zeitzone. Bitte schlagen Sie vor, dass dies eine bewährte Methode ist oder eine einfache Möglichkeit besteht.

Willkommen bei 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 Einzelrepräsentation gespeichert werden, unabhängig davon, wie sie interpretiert werden, da Sie unabhängig von Ihrer Anstrengung immer mehrdeutige Fälle haben und sie ohne eine feste Repräsentation nicht lösen können. Und Sie haben einen der schlimmsten Anwendungsfälle ausgewählt - das Planen eines Termins. Der einzig schlimmere allgemeine Anwendungsfall ist der Flugverkehr, bei dem eine Reise in einer Zeitzone beginnen und in einer anderen enden kann, möglicherweise zu einer früheren Ortszeit.

Immer, immer, IMMER in UTC speichern und in der vom Benutzer bevorzugten oder explizit angegebenen Zeitzone anzeigen. Wenn möglich, teilen Sie dem Benutzer mit, in welcher Zeitzone er den Zeitstempel voraussichtlich eingibt ( z. B. mit einem expliziten Zeitzonenfeld und einer Vorbelegung mit der von ihm bevorzugten Zone).

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

Wenn das Datum und die Uhrzeit vom Benutzer eingegeben werden und der Server diese Datums- / Uhrzeitinformationen nur zum Speichern in einer Datenbank verarbeitet und nicht erwartet, dass die eingegebene Uhrzeit an den Ort angepasst wird, an dem sie angezeigt werden (z. B.) Wenn der Benutzer "8:00 PM" eingegeben hat und es als "8:00 PM" angezeigt werden soll, unabhängig davon, wo auf der Welt es angezeigt wird), ist es die einfachste Möglichkeit, die Datums- und Uhrzeitangabe als Ortszeit ohne Zeitzonenangabe zu speichern.

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

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

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

Das andere Konzept ist das eines "Zeitausdrucks" wie "20:00 Uhr jeden Dienstag". Sie haben ausdrücklich erwähnt, dass Sie es Personen ermöglichen, Termine zu planen. 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 spezifiziert hat. Es ist am besten, dies explizit anzugeben, z. B. "20:00 Uhr jeden Dienstag in der pazifischen Zeitzone". Im Fall eines Zeitausdrucks speichern Sie diesen immer als Zeichenfolge und beziehen keine Systemzeitformate mit ein.

Sehen Sie mehr Diskussion über diese auf meinem Blog

Viele Antworten geben hier das Speichern als UTC an. Aber sei wirklich vorsichtig damit. Wenn Sie beispielsweise einen Termin um 12:00 Uhr planen, der Termin jedoch nach der Umstellung auf Sommerzeit stattfindet, was passiert dann? 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 Sendezeit 8 Uhr morgens anzeigt, da die Rückrechnung von UTC davon abhängt, wann Sie die Datumszeit betrachten. Nicht an, wenn die Datums- / Uhrzeitangabe aufgezeichnet wurde.

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

Wenn Ihr Anwendungsfall ist, dass Sie ein Unternehmen sind, das Besprechungen mit einer Person aus verschiedenen Zeitzonen abhält, und diese Informationen beispielsweise in einem Unternehmenskalender angezeigt werden sollen, können Benutzer jedoch die Uhrzeit in ihrer Zeitzone anzeigen 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 dies dst beinhaltet oder nicht. Auf diese Weise können Sie die Ortszeit immer auf etwas anderes zurückrechnen, entweder auf das, was jetzt wäre, oder auf das, was historisch beabsichtigt war. Weil Zeitzonen nicht statisch sind, wird die Sache noch komplizierter.

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