Wann hat sich die Funktion SecondsBetween geändert

[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

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

[himitsu]

Nochmal nachgedacht:
Aufgrund der bekannten Rundungen, an jede Zeit 'ne 1/4 Millisekunde dranhängen und an die Endezeit nochmal 'ne 1/4 Sekunde ... dann sollten die Rundungsfehler weg sein.
Oder selber rechnen Round(Abs(Zeit1 - Zeit2) * SecsPerDay) .

[Sir Rufo]

Gibt es da nicht so eine tolle Erfindung wie Unittests?

Damit prüft man die eigenen Gebilde (und auch implizit das, was man mitverwendet).
Im Zweifelsfall läuft es auf einen Compilerschalter hinaus, der bestimmt Unterschiede bei den Compilern eben berücksichtigt. Aber dieser Fehler rutscht dann nicht mehr durch.

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