Differences

This shows you the differences between two versions of the page.

--- technology:datumswerte [2012/10/21 12:07]
rtavassoli
+++ technology:datumswerte [2012/10/21 14:11] (current)
rtavassoli
@@ Line 11: / Line 11: @@
   - Eine Mandantenzeitzone verwenden und alle Datums-/Zeitwerte in der lokalen Zeit des Mandanten speichern,
   - Alle Datums-/Zeitwerte in UTC speichern und abhängig des Clients zur Anzeige wandeln, dabei an einigen Stellen((z.B. Berechnung von Serienterminvorkommen)) explizit speichern, welche Zeitzone zur Berechnung verwendet werden soll,
-  - Jeden einzelnen Datums-/Zeitwert gemeinsam mit der Zeitzone speichern, in der er angegeben ist.
+  - Jeden einzelnen Datums-/Zeitwert in der Uhrzeit der Zeitzone speichern, in der er angegeben ist, gemeinsam mit der Zeitzone.
 Jede Entscheidung hat Vor- und Nachteile.
 ==== Mandantenzeitzone ====
 Das wurde bisher so gemacht, siehe softelligence P.A.C., bzw. die Delphi 6 Version von PRO•M. Die Vor- und Nachteile wurden oben bereits besprochen. Solange man immer nur von einer Zeitzone ausgeht und vom Anwender genügend Mitdenken voraussetzt, dass er die Tage der Zeitumstellung korrekt angibt, bzw. selbst anpasst, ist das die einfachste Lösung. Sobald das Unternehmen aber mal Anwender in Deutschland hat, mal in England, mal in den USA, mal woanders, klappt das nicht mehr. Mitarbeiter in den USA möchten ihre Daten in USA Zeit angeben, und wenn Termine koordiniert werden müssen, muss korrekt von USA in Deutsche Zeit und zurück gerechnet werden.
-\\ \\ Man könnte das darüber regeln, dass es pro Zeitzone einen eigenen Mandanten gibt
+\\ \\ Man könnte das darüber regeln, dass es pro Zeitzone einen eigenen Mandanten gibt. Das wäre eine Lösung wenn man sich anfangs keine Gedanken gemacht hat, z.B. für die Delphi 6 Version von PRO•M. Es geht aber flexibler.
+==== Alle Werte als UTC speichern ====
+Die Lösung ist schon sehr gut. Sie hat den Nachteil, dass man die Werte in der Datenbank in UTC Zeit sieht, was in den meisten Fällen nicht der Zeit entspricht, die man selbst angegeben hat. Der andere Nachteil ist der, dass Änderungen an der Sommerzeitregelung die Konvertierung zurück in die ursprüngliche Zeit verändern könnte.
+==== Uhrzeit der Zeitzone speichern, die für die Angabe verwendet wurde, samt Zeitzone selbst ====
+Wenn ich einen Termin am 4. April 2030 um 08:00 in NY angebe, soll das immer so bleiben. Was das in UTC oder Deutscher Zeit ist, ist mir egal. Wenn ich das somit genauso abspeicher, habe ich genau das, was ich möchte. Wenn ich in der //Denormalisierung// zudem speicher, was der Offset ist (z.B. -5 Stunden für NY), bzw. die UTC Zeit selbst((und man bei Änderungen an Sommerzeitregeln nur die Denormalisierung anpassen muss)), kann man die gespeicherten Werte vergleichbar halten und auch Abfragen bauen, die auf die UTC gehen((Abfragen auf die Zeit selbst wären kompliziert, weil 08:00 alles von 20:00 am Vorabend bis 20:00 heute bedeuten kann, abhängig der Zeitzone)).
+===== Lösung =====
+  * Der Mandant hat eine Standard Zeitzone,
+  * Der Mitarbeiter übernimmt die Zeitzone vom Mandanten, sie kann aber jederzeit überschrieben werden,
+  * Datums- und Zeitangaben beinhalten immer die Zeitangaben in der Zeitzone des Mitarbeiters, gemeinsam mit der Zeitzonen Information selbst, damit man hin-und-her konvertieren kann,
+  * Die denormalisierten Daten für Abfragen beinhalten zudem Datum und Uhrzeit im UTC Format um Vergleichbarkeit von den Werten herstellen zu können und konsistente Abfragen über Datumswerte zu ermöglichen.
+Was ist mit Terminen, die eine Zeitumstellung in einer Zeitzone beinhalten? Ein Termin in Outlook, der in der Deutschen Zeitzone am 28. Oktober von 01:00-04:00 angegeben ist, wird mit einer Dauer von 3 Stunden angezeigt((obwohl es 4 Stunden sind, weil die Uhr um 3 Uhr zurück gestellt wird)). Wenn ich mir den Kalender mit US Amerikanischer Ostküstenzeit angucke, ist der Termin von 19:00-23:00 am Vorabend, und auch **4 Stunden** und nicht mehr nur 3. Es gibt also auch hierfür einige Regeln, die sich an der Konvertierung von DateTime Werten in .Net anlehnt, siehe [[http://msdn.microsoft.com/en-us/library/system.datetime.touniversaltime.aspx|Zeitkonvertierung in .Net]]:
+  * Bei von-bis Terminen wird der Start und das Ende angegeben und berücksichtigt.
+  * Liegt einer der Daten in der sogenannten //Todeszone//((2:30 am letzten Sonntag im März gibt es nicht)), wird der Datensatz abgelehnt. Wenn es aber durch Änderungen an den Regeln passieren sollte, dass eine alte Angabe in der //Todeszone// liegt, wird einfach der Standard-Offset abgezogen um die UTC-Zeit zu ermitteln. Beim hin-und-her Wandeln kommt dann eine andere lokale Uhrzeit raus((z.B. wird aus 2:30 am letzten März in 2012 1:30 in UTC Zeit, weil wir in der +1 Offset Zeitzone sind, was beim zurück Wandeln in die lokale Zeit 3:30 ist, weil dann Sommerzeit ist mit +2)),
+  * Liegt einer der Daten an einem zweideutigen Zeitpunkt((2:30 am letzten Sonntag im November gibt es zwei mal)), muss der Anwender((in einer späteren Version)) angeben welcher der Beiden gemeint ist((ich gehe fest davon aus, dass es immer nur 2 Möglichkeiten gibt. Der Default wird immer //Standardzeit// sein, und der Anwender wird vorerst nicht die Möglichkeit haben, das zu ändern)),
+  * Bei Dauerangaben ist das schwieriger. Wenn ich am 28. Oktober 2012 um 02:00 einen Termin mit einer Dauer von einer Stunde angebe, wäre die lokale Uhrzeit des Terminendes 03:00, wobei das 03:00 Sommerzeit wäre, nicht die 03:00 Standardzeit, wodurch der Termin eine Dauer von 2 Stunde bekäme. Die Anzeige wäre in beiden Fällen dieselbe, ob die Dauer mit einer oder zwei Stunden angegeben ist. D.h. dass für Berechnungszwecke die Dauer verwendet werden muss, und nicht das Ende Datum/Uhrzeit. Auch Abfragen für Zeiträume müssten das berücksichtigen, wobei man bei den von-Zeiten immer den früheren nehmen muss, bei bis-Zeiten immer den späteren, um alle UTC Datumsangaben zu erhalten((so in der Art, das wird beim Programmieren klar, ist doch nicht so schwer!))

tawiki

User Tools

Site Tools

Differences

Page Tools