Zeitenberechnungs-Unit, bitte um Tests

[BingoBongo]

Hallo allerseits,

viele kennen sicherlich das saublöde Problem, dass die Delphi-eigenen Zeitkonvertierungsfunktionen in den meisten Fällen bei Zeiten > 24 Stunden den Dienst verweigern und dann behaupten, es wäre keine gültige Eingabe oder ähnliches.
Ich habe mich bei der Programmierung eines Tools über diese Beschränkung maßlos ärgern müssen und habe mir deshalb eine kleine Unit kreiert, die dieses Manko ausbügeln soll.
Und genau um diese geht es hier.

Hier erstmal die allgemeinen Infos:

function timestring: addiert die übergebenen dezimal dargestellten Zeiten ('1,25' oder '2,3654') und gibt die Summe in der Form 13:15:56 als String zurück

function decintime5: wandelt eine Dezimalzahl in eine Zeit der Form 23:56 um und gibt sie als String zurück

function decintime8: wandelt eine Dezimalzahl in eine Zeit der Form 23:56:24 um und gibt sie als String zurück

function timeindec: wandelt einen als String übergebenen Time-Wert vom Format '13:50:34' in einen Dezimalwert um

function decodetime5: Diese Function zerlegt einen String der Art '25:15' in seine Einzelbestandteile h, min und das unabhängig von der 24 Stunden Grenze der Delphi-eigenen Routinen. Zusätzlich ist result der Funktion der real-Wert der zerlegten Zeit.

function decodetime8: Diese Function zerlegt einen String der Art '25:15:26' in seine Einzelbestandteile h, min, sek und das unabhängig von der 24 Stunden Grenze der Delphi-eigenen Routinen. Zusätzlich ist result der Funktion der real-Wert der zerlegten Zeit.


Ich möchte euch bitten, diese Unit einmal zu testen, da ich trotz eigener Tests freilich bislang nicht wirklich sicher bin, alle Fehlerquellen ausgeschlossen zu haben.
Bitte beachtet auch die Bemerkungstexte an den jeweiligen Funktionen, da manchmal noch ein zusätzlicher Hinweis drin steht, auf was geachtet werden muß.

Ich bitte um Rückmeldungen.

Bingo

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