TDate: Vergleich = 0 funktioniert nicht immer - warum?

[Hobbycoder]

Man könnte auch einfach in if Trunc(aDate) > 0 then ändern. Damit wäre der Stunden-, Minuten-, Sekunden- und Millisekundenanteil egal.

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