Zeitenberechnungs-Unit, bitte um Tests

[BingoBongo]

Wenn ich hier Dezimalzahl sage, dann meine ich eine Zahl, bei der irgend eine Ziffernkombination links vor dem Komma steht, und einige Ziffern rechts nach dem Komma. Z.Bsp.: 1,2356974 oder 21,459

Und was den Rat mit den Integerwerten angeht: ich stimme dir zu, habe aber leider keinen Einfluß auf das Zahlenformat aus der Exceltabelle. Da sind eben nicht nur Integerwerte gespeichert, sondern oftmals auch 'krumme' Zahlen. Und die wollen nun auch mal 'behandelt' werden.

Bingo

[SirTwist]

Zitat:

Zitat von BingoBongo

WDa sind eben nicht nur Integerwerte gespeichert, sondern oftmals auch 'krumme' Zahlen. Und die wollen nun auch mal 'behandelt' werden.

Ja, dann konvertiert man sie genau einmal beim Einlesen nach Integr (multiplizierne, runden, feddich) und rechnet danach mit Integerwerten weiter. Ich habe anfangs mit TTime-Werten gerechnet, was ja eigentlich nur Dezimalwerte sind und habe mir richtig herbe Ungenauigkeiten eingehandelt.

Die Darstellung an den Schnittstellen ist egal, ob als String, als Dezimalwert. Und als Schnittstelle gilt sowohl die GUI für den Anwender, als auch irgendwelche Import/Export-Funktionen. Wichtig ist die Darstellung innerhalb des Programms, die sollte möglichst genau sein und einfache Berechnungen erlauben. Das bekommst Du halt am einfachsten mit Integer-Werten hin.

[juergen]

Hallo Bingo,
etwas schmunzelnn musste ich schon, als ich mir deine Unit angeschaut habe :wink:
Ich hatte mich auch mal mit Zeitberechnungen beschäftigt und hatte mich dabei zum Anfang genauso in eine "Rechnungsorgie" verloren,
wo ich anschließend -genau wie du- nicht mehr ganz sicher war, was da alles wie berechnet wird.

Dann hatte ich alles -wie schon angemerkt- umgestellt auf Umwandlung in reine Minutenwerte als Integerwert. (17:59 Std. = 1118 Minuten)
(Zahlen aus Excel umwandeln in Minutenwerte als Integerwert)
Die Ergebnisse brauchst du nur noch durch 60 teilen und entsptrechend aufbereiten.

Damit kann man wirklich alles auch NACHVOLLZIEHBAR rechnen.

Ich kann dir auch nur anraten diese Umstellung vorzumnehmen (allein der Supportbarkeit wegen).

[shmia]

Zitat:

Zitat von SirTwist

Dezimalzahlen sind dabei viel zu ungenau (das geht an shmia).

Der Datums-/Zeittyp von Delphi ist TDateTime (intern ein Double-Wert mit 64bit=8Byte)
Ein Double-Wert hat 15 bis 16 signifikante Dezimal-Stellen.
Für den Datumsanteil werden 5 Stellen benötigt; bleiben also noch 10 Nachkommastellen für den Zeitanteil übrig.
Eine Millisekunde entspricht 1.157E-8 eines Tages.
Addiert man mehrere Double-Werte kann man mit einem Rechenfehler von wenigen Millisekunden rechnen.
Wenn man diese Ungenauigkeiten im Millisekundenbereich sich nicht erlauben kann, dann muss man tatsächlich auf einen anderen Zeitmassstab ausweichen.
Für 98% aller Anwendungen ist TDateTime aber vollkommen ausreichend. Vorallem, wenn man Arbeitszeiten aufaddiert und dann auf vollen Minuten rundet.

Ein kleiner Fallstrick lauert allerdings noch:
Angenommen man nimmt den 31.5.2005 (entsprechend 39233.0 Tage seit dem 30.12.1899) und addiert munter
Stunden drauf.
Durch Rundungsfehler kommt man dann vielleicht auf:
39245.999999994 = 12.06.2007 23:59:59
obwohl man den 13.6. erwartet hätte. Es fehlt vielleicht nur eine Millisekunde.
Aber das kann man mit folgender Funktion beheben:

Delphi-Quellcode:

function RoundToFullSeconds(dt:TDateTime):TDateTime;
const
   secondsperday = 24.0*60.0*60.0;
begin
   Result := Round(dt*secondsperday) / secondsperday;
end;