TDate: Vergleich = 0 funktioniert nicht immer - warum?

[rdeutsch]

Hallo zusammen

Heute bin ich über ein Problem gestossen, auf dass ich mir im Moment keinen Reim machen kann.
Im Programmcode gibt es Datumvergleiche ähnlich diesem hier:

Code:

var aDate: TDate;
begin
  if aDate > 0 then 
    ShowMessage('Datum > 30.12.1899');
end;

Hinweis: der Inhalt von aDate wird im Debugger mit 30.12.1899 ausgewiesen, also = 0.

Mein Problem ist nun, dass im Programmcode, welchen wir bis vor ein paar Monaten verwendet haben, die Variable auch als 0 gewertet wird und somit die Meldung nicht angezeigt wird.
Nehme ich nun den etwas aktuelleren Programmcode, dann wird die Meldung angezeigt. D.h. die Variable aDate - obwohl im Debugger immer noch mit 30.12.1899 - ist plötzlich nicht mehr 0.

In beiden Tests verwende ich jeweils die gleiche Delphiumgebung 12.1.

Gibt es irgendein Compilerschalter oder eine Einstellung im Projekt oder etwas anderes, dessen Auswirkung den oben beschriebenen Effekt hat?
Projekteinstellungen habe ich verglichen und konnte keinen Unterschied feststellen.
Im Moment bin ich wirklich ratlos und bin um jeden Tipp dankbar.

Gruss, Robert

[Union]

Weil es ein Float nach IEE-754 ist. Verwende Math.IsZero. Zudem hast Du die Variable nicht initialisiert.

[Sinspin]

Das ist eine Gleitkomma Zahl. Vergleiche (ist gleich Prüfung) gegen andere Datumswerte/Zahlenwerte sind fehleranfällig.
Solche Vergleiche haben noch nie 100% sauber funktioniert.

Entweder rundest du auf ganze Zahlen und vergleichst diese. Was dann nur ganz Tage zulässt, oder du arbeitest mit Bereichen von ein paar msec Unterschied, wenn das unbedingt sein muss.
Ein Datum was kleiner als 1000 ist, ist bei mir zum beispiel immer 0.

[rdeutsch]

Danke euch.
Ja, in diesem Beispiel ist die Variable nicht initalisiert. Im Programmcode selbst schon.
Aber was mich eben am meisten irritiert ist, dass der ältere Programmcode anders reagiert als der jetztige Programmcode. Für dies müsste es doch eine Erklärung geben.

[himitsu]

Und natürlich auch noch SameValue.

Es kommt drauf an wie und von wo der Wert kommt,
dann auch noch der Datentyp (Single oder Double, wobei TDateTime ein Double ist)
und wie die Fließkommaeinheit rechnet/vergleicht. (unterschiedliche Stetings, bezüglich Runden)
dazu dann noch wie die Fließkommaeinheit arbeitet/rechnet ... anderer CPU-Hersteller, anderes Modell use.
und
und
und

Und da Fließkommazahlen nunmal nie "genau" sind, sondern gerundet, kommt es hier eben darauf an wie gerundet wurde, wie und ob der Wert normalisiert wurde uvm.

Deine "0" könnte halt eigentlich ein 0.00000000000000000000001 sein, oder so.
Im Falle der 0 ließe sie sich genau darstellen, aber z.B. 1/3 nicht und schon kommt es drauf an, wer wie in welche Richtung gerundet hat, womit dann 1/3 eben nicht genau einem anderen 1/3 entsprechen muß.

[Uwe Raabe]

Zitat von rdeutsch:

Ja, in diesem Beispiel ist die Variable nicht initalisiert. Im Programmcode selbst schon.
Aber was mich eben am meisten irritiert ist, dass der ältere Programmcode anders reagiert als der jetztige Programmcode. Für dies müsste es doch eine Erklärung geben.

Die kann aber auch an ganz anderer Stelle liegen. Z.B. bei der Zuweisung des Wertes.

[TomyN]

Die Unit dateUtils enthält viele hilfreiche Funktionen um mit Datum und/oder Zeit umzugehen.
Aber in diesem Fall (falls kein Datum vor 1900 vorkommt) würde ich ganz trivial auf > 0.1 o.ä. vergleichen.

[ConstantGardener]

...habt ihr von 32 auf 64 Bit umgestellt? Wir hatten hier ein Problem mit Pointern die nicht auf NIL initialisiert wurden unter 64Bit. Unter 32 Bit lief alles super
auf 64 kam es zu Fehlern, da im Programmcode von NIL als Startwert ausgegangen wurde.

[rdeutsch]

Vielen Dank für eure Antworten und Tipps.

Auf 64bit wurde nicht umgestellt. Werde nun die entsprechenden Datumchecks entsprechend ändern.

[Uwe Raabe]

Zitat von himitsu:

Deine "0" könnte halt eigentlich ein 0.00000000000000000000001 sein, oder so.

Dann müsste das aber irgendwo so dort eingetragen worden sein. Obwohl ein TDate formell ein TDateTime ist und somit auch Zeitanteile speichern kann, ist die Bedeutung aber eindeutig auf ein Datum, also einen bestimmten Tag, festgelegt. Wenn dort dennoch ein Zeitanteil drin steht, dann ist das ein Fehler in der Zuweisung und ich finde man sollte diesen finden, anstatt jetzt alle Vergleiche zu korrigieren.

Die Frage ist also eigentlich: Wo kommt der Datumswert her, der dort eigentlich 0 sein sollte, es aber offenbar nicht ganz ist. Gerade eine 0 ist intern exakt darstellbar (siehe TExtendedHelper.SpecialType), was das Unschärfeargument in diesem Fall ins Leere laufen lässt. Mit einer Anpassung der Vergleiche (auf > 0) wird die eigentliche Ursache für das unterschiedliche Verhalten nur verdeckt.