Vergleich von 2 TDateTime's

[Satty67]

genau.
StrToTime('08:00') = 0.3333... Dann gibt die o.g. Rechnung nur 0.9999... statt der gewünschten 1.0

[BoolString]

Wenn ich das richtig verstanden habe, dann ging es doch aber nur um Datumswerte. Und dafür müsste die gewählte Variante doch durchaus ausreichend sein. Bei einer Addition von Stunden sieht das Ganze dann tatsächlich anders aus, weil natürlich Bruchteile durch Darstellungsungenauigkeiten unterschlagen werden können. Oder habe ich da jetzt was übersehen?

Jan

[Chemiker]

Hallo,

@Satty67: Das ist mir schon klar, dass es bei Gleitkommazahlen zu Rundungsprobleme kommen kann.

@ mkinzler: Ich habe nur das Beispiel von hoika nachgestellt und bei mir wird eine 1 ausgegeben und nicht „ergibt z.B. nicht genau 1.0 (24h = 1 Tag)“ .

Bis bald Chemiker

[Hawkeye219]

Hallo,

die Abfrage könnte auch so aussehen:

Delphi-Quellcode:

function TSemesters.IsValidDateToSemester(SemesterId: TSemesterID;
  Date: TDateTime): Boolean;
var SemesterInfo : TSemesterValue;
begin
  ... // SemesterInfo ist ein Record. SemesterBegin und SemesterEnd vom Typ TDate
  Result := {Math.}InRange(Date, StartOfTheDay(SemesterInfo.SemesterBegin),
                                 EndOfTheDay(SemesterInfo.SemesterEnd));
end;

Gruß Hawkeye

[BackOrifice]

Erstmal; Danke euch

Es geht tatsächlich nur um Tage, also die Vorkommastellen eines Doubles. Und dafür sollte ja, nach den Aussagen hier, die Genauigkeit reichen. Ich denke, ich nehm die Methode mit dem Math.InRange =)


Vielen Dank.

[hoika]

Hallo,

du hast Recht.
Ich wollte mit dem Beispiel nur auf die Gefährlichkeit
des TDateTime hinweisen, wenn man damit rechnet.

Um noch mal auf das Addieren zu kommen.

Delphi-Quellcode:

var
  tdtDateTime: TDateTime;
begin
  tdtDateTime:= StrToTime('08:00')+StrToTime('08:00')+StrToTime('08:00');
  if tdtDateTime=1.0 then
  begin
    // jippi
  end
  else
  begin 
    // oops  
  end
end;

Bei mir (und bei einem Kunden ... ;( ) landet er in oops .


Heiko