Wann hat sich die Funktion SecondsBetween geändert

[v2afrank]

Hallo,
ich benutze in einem Delphi 6 Programm die Funktion SecondsBetween. Dabei ist mir ein Fehler aufgefallen, den mann so reproduzieren kann:

Delphi-Quellcode:

procedure TForm35.Button1Click(Sender: TObject);

var
   s1,s2:string;
   d1,d2:TDateTime;
   diff:Integer;
begin
  s1:='05:23:08';
  s2:='05:23:19';
  d1:=StrToDate('16.07.2014')+StrToTime(s1);
  d2:=StrToDate('16.07.2014')+StrToTime(s2);
  diff:=SecondsBetween(d1,d2);
  Caption:=IntToStr(diff);
end;

In meinem Delphi 6 bekomme ich hier 10 raus. Mit meinem XE2 kommt die erwartete 11 raus. Ich muss allerdings 6 benutzen, da ich eine CSV Datei mit dem CSV Reader von hier einlese die noch nicht Unicode fähig ist. Gibt es außer try and error noch eine Möglichkeit heruaszufinden wann sich die Funktion geändert hat ? Mit wann meine ich dabei welche Delphi Version

[himitsu]

Wieso ist es denn wichtig wann das passiert ist?

Jetzt geht es richtig und früher war es falsch.
Im Grunde brauchst du eh nur die Versionen selber prüfen, welche ihr einsetzt und dann interessiert nur "hier geht es, aber da nicht".

Sicher das sich SecondsBetween geändert hat und nicht StrToTime?

Eventuell ist die CPU auch auf einen anderen Rundungsmodus eingestellt, z.B. durch irgendwelche Fremdkomponenten, welche einfach so an programmglobalen Dingen rumfummeln, oder durch andere Grundeinstellungen der RTL/VCL.


6? ... Unicode ... Da geht doch alles bis D2007 (D7, D8, D2005, D2006, D2007)
Also einfach mal D2007 ausprobieren und wenn es da auch noch nicht richtig geht, dann habt ihr eh pech und solltet den Code nun doch langsam mal portieren.
(Beim Kauf von XE2 konntet ihr euch ja alles runter bis D7 freischalten lassen)

[mkinzler]

Dann wäre es doch einfacher diese unicodefähig zu machen.

[v2afrank]

Momentan habe ich aber nur XE2 und 7 installiert. Klar kann ich jetzt die verschiedenen Versonen bis 2007 installieren und testen. Einfacher wäre es aber doch gewesen wenn irgendwo ersichtbar gewesen wäre. Geändert ab x.y.

Es war natürlich praktisch die Datei einfach zu nehmen und das Einlesen der CSV Dateie war erledigt.

[Dejan Vu]

Zitat von himitsu:

Wieso ist es denn wichtig wann das passiert ist?

Um zu wissen, wann der Qualitätscheck bei Emba/nprise/Codegear/Borland ausgesetzt hat.

Zitat:

Eventuell ist die CPU auch auf einen anderen Rundungsmodus eingestellt, z.B. durch irgendwelche Fremdkomponenten, welche einfach so an programmglobalen Dingen rumfummeln, oder durch andere Grundeinstellungen der RTL/VCL.

Mal sehen: Ungenauigkeit = 1 Sekunde, oder 1/86400 oder die 10/11 Stelle (30000.123456 ist ja ein auf die Sekunde genaues Datum). Double hat aber 15 signifikante stellen. Wenn ich jetzt mal annehme, das 'StrToDateTime' keine 3-4 Schutzstellen verbrät, kann es daran nicht liegen.

Habe ich einen Fehler in meinen Überlegungen?

Aber ausprobieren wäre ja interessant:

Delphi-Quellcode:

var oneSecond double;

begin
  oneSecond := (strToDateTime('16.07.2014 13:04:05')-StrToDateTime('16.07.2014 13:04:04'))*86400;
  writeln(oneSecond);
end.

Was kommt denn da raus? Bzw. mit den Zeiten vom TE?

[pertzschc]

Zitat von Dejan Vu:

Was kommt denn da raus? Bzw. mit den Zeiten vom TE?

" 9.99999605119228E-0001" mit Delphi 2010.

Grüße, Christoph

[himitsu]

Zitat von Dejan Vu:

Wenn ich jetzt mal annehme, das 'StrToDateTime' keine 3-4 Schutzstellen verbrät, kann es daran nicht liegen.

Wenn Da SecondsBetween abrundet, dann reicht schon ein Rundungsfehler von 'ner Millisekunde, in die ungünstigste Richtung.

[v2afrank]

9.99999605119228E-0001 mit Delphi 6 und XE2

[himitsu]

Alle Between-Time-Funktionen arbeiten mit Millisekunden.

Also erstmal auf Millisekunden umgerechnet, dann die Differenz gebildet und zum Schluß abgerundet (Integerdivision durch die entsprechende Zeiteinheit, hier MSecPerSec).
Es wird also 3 Mal (ab)gerundet.



Die Betweenfunktionen geben halt jede "abgeschlossene" Zeiteinheit raus und nicht die gerundeten.
In diesem Fall lieg die Lösung darin, daß an das Endedatum z.B. eine halbe Sekunde angehängt wird,
oder Emba hätte, wie z.B. bei den CompareValue-Funktionen, ein Epsilon zur Verfügung gestellt, bzw. würde runden statt abzurunden.

Zitat von Dejan Vu:

Um zu wissen, wann der Qualitätscheck bei Emba/nprise/Codegear/Borland ausgesetzt hat.

Wieso ausgesetzt?

Jetzt rechnet die Funktion doch richtig und früher war sie "kaputt".

[Dejan Vu]

Zitat von himitsu:

Zitat von Dejan Vu:

Um zu wissen, wann der Qualitätscheck bei Emba/nprise/Codegear/Borland ausgesetzt hat.

Wieso ausgesetzt?

Jetzt rechnet die Funktion doch richtig und früher war sie "kaputt".

Wurde das kommuniziert?
Ist Qualität = 'gut' oder eher und in erster Linie 'gleichbleibend', 'transparent' und vor allen Dingen 'nachvollziehbar'?

Etwas, was immer gleich ist, ist qualitativ besser, als etwas, von dem man nicht weiß, ob es noch gleich ist. Qualität ist in erster Linie ein Maß für die Wiederholbarkeit und erst dann ein Maß für Güte. McDonalds hat zum Beispiel eine sehr hohe Qualität. Schmeckt zwar beschissen, aber immer gleich, man kann sich drauf verlassen.

Aber es war polemisch. Kann nämlich sein, das das in irgend einer Release note drin stand.

@himitsu: Also werden doch die Stellen ausgereizt. Ich habe hier kein Delphi und kann das nicht nachprüfen. Danke für die Mühe.