Calc: Fehler in Zeitberechnung

[Thopag]

Libre Office 6.1.6

Bereits seit mehreren Jahren übernehme ich Daten aus einer Zeiterfassung in Calc um sie dort weiterzuverarbeiten. Problemlos.
Seit letzter Woche produziert Calc aber Falschberechnungen bei der Umrechnung in Deziaml-/Industriestunden.
Und zwar nicht nur bei neueren Werten, sondern auch alle in den Vormonaten korrekt berechneten Werte sind nun falsch.

Konkret zum Problem:
Der Eintrag in der zu verarbeitenden Zelle lautet z.B. 02.05.2019 13:15:00, der Wert, den Calc hieraus als Zeitstunde errechnet ist 13,23 müsste aber natürlich 13,25 sein.
Zeiteinträge aus anderen Tabellen werden korrekt errechnet.
Alle alten Daten aus der Zeiterfassung, die vormals korrekt umgerechnet waren, werden nun bei der Neuberechnung auch falsch berechnet.
Überschreibe ich die Date von Hand, trage also manuell 02.05.2019 13:15:00 in die Zelle ein, rechnet Calc wieder korrekt.
Ich habe aber keinen blassen Schimmer, was sich geändert haben soll. Weder bei der Zeiterfassungssoftware, noch bei Libre hat sich was geändert. Anders verfahren als die letzten Jahre habe ich auch nicht.
Lediglich Windows hat Updates eingespielt.

Der Fehler liegt offensichtlich in der Interpretation der importierten Daten, der Zelleintrag selber sieht aber aus wie immer und unterscheidet sich visuell auch nicht von meinem manuellen Eintrag.

Ergänzung:
Wandel ich in der Formatierung den importierten Wert und den manuell eingetragenen in Dezimalzahlen um, sind sie beide identisch, trotzdem wird der Importierte mit 13,23 bzw. 1 Minute zu wenig errechnet.

Irgendjemand irgendeine Idee?
Thx!

Test Zeitfehler.ods

[anon73440385]

Formatierungen helfen hier sicher nicht weiter, da die nur die Repräsentation eines numerischen Wertes darstellen. LibreOffice speichert Tage als integer Wert und die Uhrzeit als Bruchteil eines Tages. Beispielsweise ist 45000,5 der 45000ste Tag nach dem 30.12.1899 12:00 Uhr mittags (,5 ist ein halber Tag). Daher ist für eine hilfreiche Antwort zwingend erforderlich zu wissen, in welchem Format die “Zeiterfassungsdaten” vorliegen und wo daher eine Konversion der Zeiterfassungdaten erfolgt (ich weiß zum Beispiel von einem Bug bei dem Foxpro dba Daten nach Calc importiert werden und da ist der Importfilter fehlerhaft [gewesen]). Daher ist erstmal wichtig zu wissen: Ist der numerische Wert einer Zeitangabe nach dem Import schon falsch? Wenn ja, ist jede weitere Berechnung natürlich auch falsch (das ist der Fall von dem ich eigentlich ausgehe). Ausserdem geht aus Deiner Frage nicht hervor mit welcher Formel Du den Stundenanteil aus einer Zeitangabe mit Datumsanteil ausrechnest.

[Thopag]

Der Ablauf ist folgender:
Ich exportiere die Daten aus der Zeiterfassung in eine Exceldatei. Diese öffne ich mit Calc und kopiere die Daten dann in eine neue Tabelle in meiner Arbeitsdatei.
Klar liegt es nicht an der Formatierung, ich tippe entweder auf die Interpretation der Urdaten.
Der Fehler tritt übrigens auch nicht in jeder Umrechnung auf. Eher sporadisch, bzw. bei bestimmten Konstellationen.
Die Formel, mit der ich auch über Jahre nie Probleme hatte, ist simpel:

=STUNDE(A1)+MINUTE(A1)/60

Rechne ich den gleichen Wert, zB 02.05.2019 10:10:00 mit Excel um kommt korrekt 10,17 heraus, Calc ergibt eine 10,15

Ein anderes Beispiel:
03.05.2019 16:15:00 einmal aus der Datenübernahme ergibt 16,23 und das gleiche Datum von Hand eingegeben ergibt korrekt 16,25.
Beiden Werten liegt der unformatierte Wert 43588,6770833333 zugrunde.
Wobei die Handeingabe nicht immer für den korrekten Wert sorgt.
In einem anderen Datensatz ergibt auch die Handeingabe von 06.05.2019 13:00:00 nur 12,98

[Thopag]

Gebe ich in ein neues Tabellenblatt 06.05.2019 13:00 ein und will mittels =stunde(a1)+minute(a1)/60 die Industriestunden ermitteln, bekomme ich auch nur 12,98333 statt 13,00

[anon73440385]

Leider kann ich das mit meiner Calc Version (meinen Settings) nicht nachvollziehen. Ich installier mir mal 6.1.6 (Du verwendest Windows 10 oder was sonst ?) Eventuell kanst Du die Datei mit dem einen Eintrag und der fehlerhaften Berechnung als .ods hier hochladen (Hab Dir dazu das notwendige Karma verschafft)

[anon73440385]

Habe mir gerade 6.1.6.3 auf mein Windows installiert und sehe nun auch 12,98333 für 06.05.2019 13:00:00

[Thopag]

Vielen Dank für Deine Mühe.
Ich habe das File an die Frage angehängt.
Ja es läuft 6.1.6.3, 32bit auf Win10, 1803

Gerade auf einem anderen Rechner mit LibreOffice 6.1.5.2, 64bit mit Win 10, 1809 getestet, aber auch hier macht er bei einer kombinierten Datums- und Zeiteingabe aus einer vollen Stunde 59 Minuten.
Und das ist, wie gesagt, neu aufgetreten.
Ich habe nicht schlecht geschaut, als der anfing und sich in ein paar tausend Datensätzen die Rechenergebnisse änderten…

[anon73440385]

Also ich hatte zuvor unter Windows 10 1903 64-bit mit LibreOffice 6.2.4.2, sowie LibreOffice 6.2.4.2 unter Linux openSUSE 15.1 64-bit getestet und in beiden Fällen konnte ich das Problem nicht nachvollziehen. Ich sehe darin einenn klassischen Rundungsfehler, da eine Zahl im Speicher nie exakt abgelegt werden kann, und wenn programmtechnisch nicht abgeschnitten wird, wirkt sich ein (kummulierter) Rundungsfehler manchmal so aus. Mach mal in Zelle B1 die Formel =RUNDEN(A1;8) und dann davon =STUNDE(B1)+MINUTE(B1) / 60 und da kommt dann 13,0 raus. Daran sieht man, dass es sich um ein Rundungsproblem handelt und die Calc Funktionen STUNDE() und MINUTE() keine passenden Vorkehrungen treffen. Vielleicht kannst Du unter https://bugs.documentfoundation.org eine Bug Report finden und das Thema ist bereits adressiert. Ich finde da leider nichts, obwohl ich weiß, dass das ein Thema ist. Für mich jedenfalls ist das ein Bug.

[anon73440385]

Ich kann Dir also als Lösung nur anbieten, Deine Formel nach:
=STUNDE(RUNDEN(A1;8)) + MINUTE(RUNDEN(A1;8)) / 60 zu ändern oder auf 6.2.4 zu wechseln und zu hoffen, dass es keine Regression geben wird.

[Lupp]

Mit dem Datum-Zeit-Wert im angehängten Beispiel ist
=(A1-INT(A1))*24 = 12.9999999999418, also “signifikant” (im Rahmen der arithmetischn Genauigkeit des Rechnens i IEEE 754 Double) weniger als 13. Das ist ein Effekt, der in der numerischen Mathematik als “Auslöschung signifikianter Ziffern” bzw. “Einschleppung insignifikanter Ziffern” bekannt ist.
Die Rundung bei der Anzeige von Zeiten in “Doppelpunkt-Formaten” ist nicht “kaufmännisch”, sondern immer abwärts.
Für die Funktion MINUTE() ist spezifiziert:

Semantics: Extract from T the minute value, 0 through 59, as per a clock. This is equal to:
DayFraction=(T-INT(T))
HourFraction=(DayFraction*24-INT(DayFraction*24))
Minute=INT(HourFraction*60)  

und das liefert im gegebenen Beispiel tatsächlich 59 als Zahl der Minuten.
Wenn eine jüngere Funktion wieder 60 anzeigt, ist das genau genommen ein Verstoß gegen die Spezifikation - aber man will sich ja mit den Anwendern vertragen, die die Hintergründe nicht kennen. In einigen Jahren wird das Problem schärfer, weil die anwachsenden Ganzzahlen für das Datum beim Abziehen um zum Zeitanteil zu kommen, mehr insignifikante Stellen einschleppen können.

Gleitkommazahlen mit fester Anzahl von dyadischen Ziffern können eben keine beliebig feine Auflösung liefern.
Ob man in Zukunft für die Anwendung durch Nichtmathematiker ein spezielles internes Datumsformat aus zwei Double-Zahlen schaffen wird?

===Edit 2019-06-25 09:50 UTC===
Hmm. Das ist natürlich eine Erklärung, nicht die Lösung. Lösungen:
Auf die aktuellste Version updaten. (Bei meinen Tests 6.3 - aber noch Beta.)
Explizit runden, um das ungewohnte Immer-Abrunden auszutricksen.

[anon73440385]

Ich bin ja nicht jemand, der häufig Spezifikationen liest, aber der Knackpunkt liegt meines Erachtens in T und da hat der Evaluator, wie das OASIS Dokument das nennt, durchaus einen gewissen Spielraum, wenn ich den Abschnitt 4.3.1 ( in Verbindung mit 4.3.2) im Open Document Format for Office Applications (Part 2) auch nur ansatzweise richtig verstehe.

[Lupp]

T ist der zu bearbeitende Datum-Zeit-Wert in Calc, und der ist vom Typ Double wie alle Zahlen in Calc. Der Rest ist in diesem Fall, bei dem es sich um direkt eingegebene DZW handelt, der "Recognition’ überlassen. Ich würde erwarten, dass sie im gegebenen Fall (fast) genaiu das Umgekehrte tut, was der OQ hernach möchte, nur dfass sie eine ziemlich große Ganzzahl (heute z.B. 43642) fürs Datum addiert - und das schiebt im Beispiel von den 53 Bits Mantisse der Double Zahl 15 oder 16 ins Nirwana. Bei der späteren Normalisierung des Bruchanteils werden dafür insignifikante Nullbits eingeschleppt.(Division durch 1440 geht eben selten auf.)

[Lupp]

Ja, wie machen’s dann die Versionen, die den Erwartungen der Standarduser entsprechen?. Ich vermute, die Recognition-Conversion rundet zwischendurch (Standardrundung) auf Millisekunden (Microsekunden gingen auch noch), so dass die Addition der Ganzzahl nichts mehr hinaus schiebt. Man verzichtet so halt auf einen Teil der an sich möglichen Auflösung. Eigentlich sollte es genügen, auf die Reihenfolge der Summanden zu achten. (GanzZahl + BruchAnteil ststt umgekehrt.)
Die gute Absicht kann natürlich das Ziel verfehlen, wenn der User zwischendurch wieder etwas wie +43000000 - 43000000 rechnet.

[Thopag]

Vielen Dank für eure Mühen und Antworten.

Mathematisch ist das Problem nun für mich nachvollziehbar und logisch, auch wenn damit die Funktion nicht das erfüllt, was gewünscht ist.
Allerdings ist es auch mit der 6.2.4.2 wieder eliminiert, so dass sich mit einem Wechsel auf diese Version das Problem vorerst erledigt hat. Aber den zweiten Weg mit der entsprechenden Runding merke ich mir auch.

Nochmal 1000Dank!