TDate: Vergleich = 0 funktioniert nicht immer - warum?

[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 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.

[rdeutsch]

Zitat von Uwe Raabe:

Zitat von himitsu:

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 von rdeutsch:

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 von Hobbycoder:

Man könnte auch einfach in 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 von Uwe Raabe:

Zitat von Hobbycoder:

Man könnte auch einfach in 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 von Hobbycoder:

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).

[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.