technology:datumswerte
Differences
This shows you the differences between two versions of the page.
|
technology:datumswerte [2012/10/21 14:03] rtavassoli [Lösung] |
technology:datumswerte [2012/10/21 14:11] (current) rtavassoli |
||
|---|---|---|---|
| Line 29: | Line 29: | ||
| * 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.1350821023.txt.gz · Last modified: 2012/10/21 14:03 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
