Date Vergleich

[mcbain]

Hallo,
ich habe ein seltsames Problem.
Ich vergleiche Dates miteinander und bekomme auf unterschiedlichen Systemen unterschiedliche Ergebnisse:
Beispielsweise überprüfe ich ob ein Ereignis innerhalb eines Zeitraumes liegt.
Mein Code:

Code:

...
var start: TDate;
    ende: TDate;
    ereignis: TDate;
begin
...

if (ereignis >= start) and
   (ereignis <= ende) then

...

Auf Maschine 1 funktioniert das korrekt.
Auf Maschine 2 läuft er mir einen Tag zu spät in die Schleife, wenn start gleich ereignis ist.

Wenn ich mit CompareDate arbeite läufts bei beiden Maschinen.
Hat jemand eine Idee warum das so ist?

Vielen Dank.
Gruß
mc

[DeddyH]

AFAIK enthalten auch TDate-Variablen einen Zeitanteil. Funktioniert es, wenn Du den jeweils mit DateOf nullst?

Delphi-Quellcode:

if (DateOf(ereignis) >= DateOf(start)) and
   (DateOf(ereignis) <= DateOf(ende)) then

[Perlsau]

Stimmt, hab's eben ausprobiert: Mit DateOf(Datum) erfolgt die Berechnung korrekt. TDate ist tatsächlich vom Typ TDateTime, das wiederum vom Typ Double ist.

Delphi-Quellcode:

procedure TFormMain.Button1Click(Sender: TObject);
Var
  start,
  ende,
  ereignis : TDate;
  Aus      : String;

begin
  start    := DateOf(StrToDate('01.03.2014'));
  ende     := DateOf(StrToDate('30.04.2014'));
  ereignis := DateOf(DateTimePicker1.Date);

  if (ereignis >= start) and
     (ereignis <= ende) then
     Aus := 'innerhalb' else
     Aus := 'außerhalb';

  ShowMessage(Aus);
end;

[Sir Rufo]

Das ist nicht seltsam, sondern liegt in der Natur der Sache begründet.

TDate ist ein double und somit ein FloatingPoint-Type, und durch die systembedingten Ungenauigkeiten (nicht alle Werte können wirklich korrekt dargestellt werden) werden FloatingPoint-Werte immer auf Ähnlichkeit (mit einem Epsilon = maximale Abweichung) und nicht auf absolute Gleichheit geprüft.

CompareDate berücksichtigt dieses eben ;)

[baumina]

Zitat:

Zitat von Sir Rufo (Beitrag 1253367)

CompareDate berücksichtigt dieses eben ;)

Ja, CompareDate macht ein Trunc.

[Sir Rufo]

Zitat:

Zitat von baumina (Beitrag 1253374)

Zitat:

Zitat von Sir Rufo (Beitrag 1253367)

CompareDate berücksichtigt dieses eben ;)

Ja, CompareDate macht ein Trunc.

Wie das dort berücksichtigt wird ist egal, solange es korrekt ist ;)

[mcbain]

Vielen Dank für eure Antworten.
ich dachte mir ursprünglich auch, dass es an einem Zeitanteil scheitern könnte, aber da der Typ ja nicht Datetime sondern Date ist, dachte ich der Zeitanteil wird dabei ignoriert.

Alles klar, dann werde ich in Zukunft vergleiche mit CompareDate machen.

[himitsu]

TDate und TTime haben grundsätzlich erstmal nur syntaktischen Charakter, also mehr für den Programmierer.

Intern sind TDateTime, TDate und TTime alle gleich (Double) und könnten sowohl Uhrzeit, als auch Datum enthalten. (wenn derjenige nicht aufpasst, welcher diese Typen/Variablen mit Werten füllt)

[sx2008]

TDateTimePicker hat schon seit ewigen Zeiten einen Bug.
Wenn man das

Delphi-Quellcode:

Property [TDateTimePicker].Date

abfragt würde man ja erwarten dass man nur den Datumsanteil bekommt.
Schlieslich gibt es auch noch die Properties

Delphi-Quellcode:

DateTime

und

Delphi-Quellcode:

Time

.
Man bekommt aber das Datum + aktuelle Uhrzeit zurück.
Abhilfe bringt die Zeile:

Delphi-Quellcode:

ereignis := DateOf(DateTimePicker1.Date);

Die anderen DateOf() bei StrToDate() braucht man nicht.

Möglicherweise hat man sich später nicht mehr getraut diesen Bug abzustellen weil dies existierenden Code brechen könnte...

[himitsu]

Ich glaub den Bug hat man inzwischen sogar "schon" behoben. (in irgendeinem der XEs)

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1253467)

Ich glaub den Bug hat man inzwischen sogar "schon" behoben. (in irgendeinem der XEs)

Aber nicht in XE5:

Delphi-Quellcode:

function TCommonCalendar.GetDate: TDate;
begin
  Result := TDate(FDateTime);
end;

function TDateTimePicker.GetTime: TTime;
begin
  Result := TTime(FDateTime);
end;

Insofern bekommt man faktisch dasselbe Ergebnis über Date, Time oder DateTime.

Interessanterweise wird beim Setzen dieser beiden Properties nur jeweils die Date- bzw. Time-Komponente des Werts übernommen. Die jeweils andere bleibt unverändert.

[himitsu]

*durchstreich*
Ich war mir ganz sicher, daß es schonmal ging. (ich hoffe nur, ich bin da nicht mit DevExpress durcheinandergekommen ... die haben/hatten auch solche Bugs)

Zitat:

Möglicherweise hat man sich später nicht mehr getraut diesen Bug abzustellen weil dies existierenden Code brechen könnte...

Hier würde ich das ja einfach hart abändern, so daß es nun richtig geht. :twisted:
Oder man fängt mit Properties an, die sich plötzlich RealDate und RealTime nennen, oder so.

Aber da es hier auch das .DateTime gibt und somit keine Funktion verloren geht, haben einfach die Pech gehabt, die es bisher falsch gemacht haben. :stupid:


Jetzt müsste man nur mal nachsehn, ob es nicht schon einen QC dafür gibt.

[Popov]

Theoretisch darf es keine Rundungsfehler geben, aber bei Millisekunden ist man da anscheinend nicht so genau. TDateTime ist ja nur eine Zahl, was vor dem Komma ist, sind Tage, nach dem Komma die Stunden, Minuten, Sekunden und Millisekunden.

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  h, n, s, ms: Integer;
  t: TDateTime;
  d: Double;
begin
  t := EncodeTime(11, 20, 30, 998);

  d := t * 24;
  h := Trunc(d);

  d := (d - h) * 60;
  n := Trunc(d);

  d := (d - n) * 60;
  s := Trunc(d);

  d := (d - s) * 1000;
  ms := Trunc(d);

  //ShowMessage('Zeit: ' + TimeToStr(t));
  ShowMessage(Format('h: %d, n: %d, s: %d, ms: %d', [h, n, s, ms]));
end;

Bei der Millisekunde wird es ungenau im 1/1000 Sekunde.

[Furtbichler]

Zitat:

Zitat von Popov (Beitrag 1253482)

Theoretisch darf es keine Rundungsfehler geben

Theoretisch darf es natürlich Rundungsfehler geben. Praktisch gibt es sie ja auch. Das liegt an der Natur des 'Double'.

Zitat:

Zitat von Sir Rufo (Beitrag 1253367)

...nicht alle Werte können wirklich korrekt dargestellt werden...

Bei ganzen Zahlen (also nur das Datum z.B.) stimmt das nicht, diese werden genau angegeben. Daher wundert es mich ein wenig. Oder anders ausgedrückt: Ich wäre auch drauf reingefallen.

PS: Im Datenbankbereich gibt es diese Probleme interessanterweise nicht, obwohl man annehmen kann, das ein DateTime auch als Double gespeichert wird. Ergo stimmt diese Annahme nicht, denn

Code:

WHERE myDateTimeColumn BETWEEN @SomeDate and @SomeOtherDate
  or  (myOtherDateTimeColumn => @SomeDate and myOtherDateTimeColumn <= @SomeOtherDate)

funktioniert immer. In der Tat wird ein DateTime zumindest im SQL-Server als INTEGER-INTEGER abgelegt (8 Bytes), wobei die erste Zahl die Anzahl der Tage seit 1.1.1900 und die Zweite Zahl die Anzahl der Ticks seit Mitternacht angibt, wobei hier blöderweise 300 Ticks = 1 sec ist, womit wieder eine Ungenauigkeit eingeführt wird, da man die letzte ms-Stelle mal wieder nicht genau treffen kann. :wall:

Irgendwie habens die Informatiker mit Ungenauigkeiten. :stupid:

[himitsu]

Und je öfter man "nacheinander" rechnet, um so mehr können/werden sich Rundungsfehler "aufsummieren".

[Furtbichler]

Zitat:

Zitat von himitsu (Beitrag 1253528)

Und je öfter man "nacheinander" rechnet, um so mehr können/werden sich Rundungsfehler "aufsummieren".

Wenn Du nicht gerade sehr kleine mit sehr großen Zahlen miteinander multiplizierst, ist das irrelevant. Aber die Thematik ist gefühlte 1.000.000,00000000000128 (double halt) mal durchgekaut.