technology:datumswerte
Differences
This shows you the differences between two versions of the page.
|
technology:datumswerte [2012/10/21 14:02] rtavassoli |
technology:datumswerte [2012/10/21 14:11] (current) rtavassoli |
||
|---|---|---|---|
| Line 26: | Line 26: | ||
| * 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. | * 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. 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]]: | + | 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. | * 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 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)) | + | * 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!)) | ||
technology/datumswerte.1350820964.txt.gz · Last modified: 2012/10/21 14:02 by rtavassoli
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
