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:

Zitat von rdeutsch (Beitrag 1536776)

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:

Zitat von himitsu (Beitrag 1536777)

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.

[Hobbycoder]

Man könnte auch einfach in

Delphi-Quellcode:

if Trunc(aDate) > 0 then

ändern. Damit wäre der Stunden-, Minuten-, Sekunden- und Millisekundenanteil egal.

[rdeutsch]

Zitat:

Zitat von Uwe Raabe (Beitrag 1536786)

Zitat:

Zitat von himitsu (Beitrag 1536777)

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

.. Mit einer Anpassung der Vergleiche (auf > 0) wird die eigentliche Ursache für das unterschiedliche Verhalten nur verdeckt.

Da stimme ich dir zu, aber das Problem ist, dass sich an der Basis für die Zuweisung des Datumfeldes nichts geändert hat.
In meinem konkreten Programmcodeabschnitt erhält die Datumsvariable ihren Wert über einen Soap-Request. Weder am Service, der WSDL-Importunit noch im verarbeiteten Codeteil hat es Änderungen gegeben.

Die "einzige" Änderung der bisherigen Applikation zur aktuellen Version ist, dass auf UTF8 umgestellt wurde. D.h. z.B. persistente Felder wurden von TStringField auf TWideStringField geändert. Ansonsten wurde nichts verändert.

[Uwe Raabe]

Zitat:

Zitat von rdeutsch (Beitrag 1536788)

Da stimme ich dir zu, aber das Problem ist, dass sich an der Basis für die Zuweisung des Datumfeldes nichts geändert hat.
In meinem konkreten Programmcodeabschnitt erhält die Datumsvariable ihren Wert über einen Soap-Request.

Dann würde ich zunächst an genau der Stelle (wie auch beim Vergleich) schauen, ob im Datumswert tatsächlich alle Bytes auf 0 stehen (z.B. eine Watch-Variable als Hex darstellen). Dem Debugger-Visualizer für TDate würde ich da nur begrenzt trauen.

Natürlich ist ein toleranterer Vergleich schnell und einfach umzusetzen. Trotzdem bleibt die eigentliche Ursache weiterhin verborgen. Das kann ja auch noch ganz andere Probleme verursachen, die ihr bloß noch nicht bemerkt habt. Wenn nicht, umso besser. Ich persönlich hätte dabei aber ein schlechtes Gefühl.

Zitat:

Zitat von Hobbycoder (Beitrag 1536787)

Man könnte auch einfach in

Delphi-Quellcode:

if Trunc(aDate) > 0 then

ändern. Damit wäre der Stunden-, Minuten-, Sekunden- und Millisekundenanteil egal.

Guter Hinweis! Ich würde in dem Fall dann sogar für DateOf aus System.DateUtils plädieren, das intern zwar dasselbe tut, aber die Intention besser darstellt.

Insbesondere würde ich das schon bei der Zuweisung machen. Dann kann man sich die Anpassung der Vergleiche nämlich sparen.

[Hobbycoder]

Zitat:

Zitat von Uwe Raabe (Beitrag 1536790)

Zitat:

Zitat von Hobbycoder (Beitrag 1536787)

Man könnte auch einfach in

Delphi-Quellcode:

if Trunc(aDate) > 0 then

ändern. Damit wäre der Stunden-, Minuten-, Sekunden- und Millisekundenanteil egal.

Guter Hinweis! Ich würde in dem Fall dann sogar für DateOf aus System.DateUtils plädieren, das intern zwar dasselbe tut, aber die Intention besser darstellt.

Insbesondere würde ich das schon bei der Zuweisung machen. Dann kann man sich die Anpassung der Vergleiche nämlich sparen.

Wenn ich mit reinen Datumswerten arbeite, mache ich das immer (mit Trunc). TDate ist eigentlich ein TDateTime und das ist eigentlich Double. Und einen Integer gegen eine Double zu testen ist, sofern die Zuweisung nicht unmittelbar davor passiert, eigentlich nie eine gute Idee.

[Uwe Raabe]

Zitat:

Zitat von Hobbycoder (Beitrag 1536791)

TDate ist eigentlich ein TDateTime und das ist eigentlich Double. Und einen Integer gegen eine Double zu testen ist, sofern die Zuweisung nicht unmittelbar davor passiert, eigentlich nie eine gute Idee.

In einem 64-Bit Double lassen sich Ganzzahlwerte bis 2^53 exakt und ohne Verlust speichern. Das ist wesentlich mehr als ein 32-Bit-Integer haben kann. Warum sollte das dann keine gute Idee sein?

Wenn in einem TDate kein Wert drin steht, der sich exakt in einen Integer umwandeln lässt, dann liegt meiner Meinung nach irgendwo ein Fehler vor. Das kann bei der Zuweisung sein oder einer anderen Manipulation (z.B. als var-Parameter einer Methode).