Theoretisch darf es keine Rundungsfehler geben
Theoretisch darf es natürlich Rundungsfehler geben. Praktisch gibt es sie ja auch. Das liegt an der Natur des 'Double'.
...nicht alle Werte können wirklich korrekt dargestellt werden...
Bei ganzen Zahlen (also nur das Datum z.B.) stimmt das nicht, diese werden genau angegeben. Daher wundert es mich ein wenig. Oder anders ausgedrückt: Ich wäre auch drauf reingefallen.
PS: Im Datenbankbereich gibt es diese Probleme interessanterweise nicht, obwohl man annehmen kann, das ein DateTime auch als Double gespeichert wird. Ergo stimmt diese Annahme nicht, denn
Code:
WHERE myDateTimeColumn BETWEEN @SomeDate and @SomeOtherDate
or (myOtherDateTimeColumn => @SomeDate and myOtherDateTimeColumn <= @SomeOtherDate)
funktioniert immer. In der Tat wird ein DateTime zumindest im
SQL-Server als INTEGER-INTEGER abgelegt (8 Bytes), wobei die erste Zahl die Anzahl der Tage seit 1.1.1900 und die Zweite Zahl die Anzahl der Ticks seit Mitternacht angibt, wobei hier blöderweise 300 Ticks = 1 sec ist, womit wieder eine Ungenauigkeit eingeführt wird, da man die letzte ms-Stelle mal wieder nicht genau treffen kann.
Irgendwie habens die Informatiker mit Ungenauigkeiten.
