TDateTime kann nicht korrekt verglichen werden

[berens]

Hallo zusammen!

Nachdem ich schon wieder ernsthaft an mir selbst gezweifelt habe, bin ich doch langsam am Überlegen, ob das Folgende nicht vielleicht doch ein Delphi-Bug sein könnte:

Vorab: Ich lasse alle TDateTime-Werte * Sekunden pro Tag nehmen (nur den Nachkommateil natürlich), um die Anteiligen Sekunden zu ermitteln (gerundet) und teile dies dann wieder durch die Sekunden pro Tag. Das hat den Vorteil, dass ich diese TDateTime-Werte immer auf die volle Sekunde gerundet habe, damit ich beim Vergleichen keine Abweichungen oder Fehler durch z.B. Millisekunden habe.

Leider kommt es manchmal vor, dass Delphi irgendwie scheinbar zu ungenau Arbeitet.

Auf dem beigelegten Screenshot kann man folgendes sehen:

Wir befinden uns in einer meiner Prozeduren. (Die Variablen sind alle nur für diesen Screenshot erstellt, also bitte nicht wegen der Benennung meckern :stupid:)

u.a.:

Delphi-Quellcode:

var
  dt: TDateTime;
  dtErsterDesMonats: TDateTime;
  a, b: TDateTime;
  e, f: string;
  t: string;

_NextFromDateTime ist ein TDateTime-Wert, welcher der Prozedur übergeben wird. Er soll im Laufe der Prozedur mit dt verglichen werden.

Am Haltepunkt auf dem Screenshot sehen wir in der Liste der überwachten Ausdrücke und lokalen Variablen, dass dt == _NextFromDateTime ist. Sowohl als Double, Float und String.

Lediglich die TDateTime-Werte unterscheiden sich scheinbar(!) da z.B. (a = b) und (dt = _NextFromDateTime) jeweils False ergibt. In der Auswertung werden TDateTime-Werte jedoch ausschließlich als String angezeigt (dd.mm.yyyy HH:nn), was sich auch beim Umschalten auf "Gleitkomma" o.ä. bei den überwachten Ausdrücken nicht ändert!

Tja, und nun?

1) Wie kann ich beim Debuggen sehen, welchen (Gleitkommawert) die beiden TDateTime-Variablen haben? Der Typcast als Float oder Double gibt beide ja als identisch aus?

2) Wie kann ich TDateTime-Werte möglichst einfach korrekt vergleichen
3) , so dass höchstens die Sekunden, nicht aber Millisekunden vergleichen werden?

Danke schonmal. :/

[Deep-Sea]

Mal kurz drei Möglichkeiten:

1. Decodiere das Datum (DecodeDateTime, Unit DateUtils) und vergleiche die einzelnen Teile miteinander.
2. Wandle das Datum in einen Unix-Timestamp um (DateTimeToUnix, Unit DateUtils) und vergleiche diese. Sie sind nur Sekundengenau.
3. Nutze die Funktion SameValue der Unit Math und passe den Parameter Epsilon entsprechend an.

[generic]

Ich denke, dass es tatsächlich an den Rundungsdifferenzen liegen kann.
Schau mal in die Unit DateUtils.
Dort sind Vergleichsfunktionen für Datum drin.
Ich meine, dass die dort sogar, etwas Source gegen die Rundungsdiffs haben.

Im Zweifelsfall einfach dein Datum nehmen, mit Sekunden am Tag multiplizieren und mit trunc() in Integer wandeln und diesen vergleichen.

[Deep-Sea]

Zitat:

Zitat von generic (Beitrag 1081574)

Im Zweifelsfall einfach dein Datum nehmen, mit Sekunden am Tag multiplizieren und mit trunc() in Integer wandeln und diesen vergleichen.

Dann aber bitte Int64 - sonst wird das nix. (Ist aber dann fast das gleiche wie mein Vorschlag mit dem Unix-Timestamp.)

[berens]

Das scheinen durchaus sinnvolle und umsetzbare Lösungansätze zu sein.
Vielen Dank!

Hat noch jemand eine Idee bzgl. der Anzeige in der Liste überwachter Ausdrücke?

[mischerr]

Hallo

ich würde folgendes tun...

Zitat:

1) Wie kann ich beim Debuggen sehen, welchen (Gleitkommawert) die beiden TDateTime-Variablen haben? Der Typcast als Float oder Double gibt beide ja als identisch aus?

Code:

  OutputDebugString(pchar(FormatDateTime('dd.mm.yyyy hh:nn:ss.zzz', now)));

Zitat:

2) Wie kann ich TDateTime-Werte möglichst einfach korrekt vergleichen
3) , so dass höchstens die Sekunden, nicht aber Millisekunden vergleichen werden?

Code:

uses DateUtils;

if SecondsBetween(now, then)=0 then...

[berens]

Zur Info:

Delphi-Quellcode:

    OutputDebugString(pchar(FormatDateTime('dd.mm.yyyy hh:nn:ss.zzz', a)));
    OutputDebugString(pchar(FormatDateTime('dd.mm.yyyy hh:nn:ss.zzz', b)));
    OutputDebugString(pchar(FormatDateTime('dd.mm.yyyy hh:nn:ss.zzz', dt)));
    OutputDebugString(pchar(FormatDateTime('dd.mm.yyyy hh:nn:ss.zzz', _NextFromDateTime)));

Liefert jeweils 100% identische Werte, obwohl -wie erwähnt- dies Werte unterschiedlich sind.

SecondsBetween scheint der allereinfachste Lösungsansatz zu sein. Danke :)

[berens]

Thema vorläufig erledigt. Danke :) (Muss man Antworten, um "Offene Frage" herauszunehmen?)

[berens]

Einen "Nachtrag" noch, da ich leider den letzten Eintrag nicht mehr bearbeiten kann:

Mir ist gerade ein uralter Trick eingefallen, mit dem ich vor langer Zeit schonmal ein änhliches Problem gelöst/umgangen habe:

Delphi-Quellcode:

NeuerDateTimeWert := StrToDateTime(DateTimeToStr(AlterDateTimeWert));

"Erschreckend" an der Sache ist, dass Delphi aus AlterDateTimeWert = 05.01.2011 10:52:11 --> NeuerDateTimeWert = 05.01.2011 10:52:10 macht. (Rundungsproblematik beachten! laut Überwachung lokaler Variablen)

Identisch ist natürlich in der Überwachung: DateTimeToStr(AlterDateTimeWert) = '05.01.2011 10:52:11' und StrToDateTime(DateTimeToStr(AlterDateTimeWert)) = 05.01.2011 10:52:10.

Somit scheint Delphi bei der Darstellung von "nicht runden" TDateTimeWerten in der überwachung lokaler Variablen und Liste überwachter Ausdrücke NICHT die Funktion DateTimeToStr() zu benutzen, sondern etwas selbstgebasteltet.

Finde ich persönlich für gescheites Debuggen sehr, sehr fragwürdig, denn man sollte schon erwarten können, dass der menschenlesbare Wert von TDateTime identisch ist mit DateTimeToStr() eben dieses Wertes...

Feedback dazu erwünscht, vielleicht mache ja ich was falsch. Ansonsten: sollte man das mal wirklich als Delphi-Bug posten?

[WM_CLOSE]

Es ist doch dein Problem, dass du einen Floatwert direkt vergleicht. Man muss entweder Bereiche festlegen, oder das nach dem Komma abschneiden. Oder liefert dir SQRT(2) einen exakten Wert.
Das ist kein Delphi-Bug

[berens]

Es geht mir hier (aktuell) weniger um die Problematik, dass ich beim Vergleichen von TDateTime- oder Float-Werten zusätzlichen Programmieraufwand habe, weil bei z.B. dem einen Wert noch 600 ms eingerechnet sind, die bei dem Anderen fehlen und deshalb Beide nicht identisch sind.

Es geht mir drum, dass der Wert AlterDateTimeWert (TDateTime) in der "Liste überwachter Ausdrücke" von Delphi 10 Sekunden am Ende hat. Die Darstellung in der "Liste überwachter Ausdrücke" erfolgt in Delphi ja als String. Man (oder zumindest ich) denkt also: Der dargestellte Wert einer TDateTime entspricht DateTimeToStr(Variable).

Wenn ich mir nun aber DateTimeToStr(Variable), also in diesem Fall DateTimeToStr(AlterDateTimeWert) in der "Liste überwachter Ausdrücke" anzeigen lasse, erhalte ich 11 Sekunden am Ende.

Hier wird ja nichts "verglichen" in dem Sinne. Ich lasse den Wert einfach nur zweimal ausgeben. Einmal als String, einmal als TDateTime, den Delphi freundlicherweise auch direkt umwandelt in String. Also habe ich letztendlich doch zwei Strings für ein und den selben Wert. Tja, jetzt unterscheiden sich aber die Strings. Du kannst mir doch nicht ernsthaft erzählen wollen, dass dies korrekt oder sogar gewünscht ist?

---

Bzgl. vergleichen von TDateTime oder FloatWerten: Wenn ich beim Debuggen für die Variablen a und b in der Liste überwachter Ausdrücke die Werte angezeigt bekomme (beides Mal jeweils als Beispiel 0,123456789012345), und diese Werte 100% identisch sind, aber gleichzeitig (a=b) False ergibt, dann empfinde ich das nicht als Benutzerfreundlich. Ich wüsste zumindest nicht, wie ich Delphi dazu prügeln kann, mir 20 oder 30 Nachkommastellen anzuzeigen. Ich kann nur etwas korrigieren wenn ich weiss, dass ich etwas falsch gemacht habe. Wenn Delphi mir beim Debuggen sagt "A ist gleich B" aber die Abfrage "Ist A gleich B" liefert "Nein" zurück, steh ich halt schon erstmal blöde da.

Ich frage ich mich, und Dich, WM_CLOSE, woher soll man das auf Anhieb wissen, dass man sich auf die von Delphi zurückgegebenen Werte nicht verlassen darf? Habe ich im Handbuch irgendwo einen Paragraphen überlesen in dem steht: "Die Werte der Liste überwachter Ausdrücke und lokaler Variablen dienen nur zum groben Überblick der ungefähren Werte während des Laufzeit des Programmes. Sie spiegeln nicht zwangsläufig die tatsächlichen Werte wieder."?

[WM_CLOSE]

Sorry, ich dacht bei >250 Beiträge weiß man das, Hier im Forum und auch auf der Delphipraxis wurde schon ein paar mal davor gewarnt, dass alles, was keinen klaren Wert auch keine verlässlichee Information bietet. Ich wollte dir nicht zu nahe treten.:oops:

PS: Bitte trampelt den Thread und mich deswegen nicht nieder

[berens]

;) Ne kein Problem.

Umso mehr guck ich gerade doof aus der Wäsche zur Erfahren, dass es scheinbar tatsächlich "Grundwissen" von Delphi ist, dass die Werte in der Liste ungenau sind. oO

Naja, jetzt bin auch ich wieder ein Stück schlauer. Wenn man das weiss, dann kann man sich ja auch drauf einstellen und entsprechend reagieren.

Danke für die Aufklärung :-D