(In)konsistente Zeitstempel, mysteriöse zeitliche Reihenfolge im Logfile

Können Datum und Uhrzeit nur in Einzelteilen ausgelesen werden? ($A_YEAR, $A_MONTH...)
Besteht dabei nicht die Gefahr, dass wenn es ganz schlecht läuft man ein Jahr daneben liegt?

Angenommen, man beginnt zufällig am 31.12.2022 um 23:59:59 das Jahr zu lesen und danach den Monat.
Dummerweise springt die Systemzeit genau zwischen den beiden Leseoperationen auf 01.01.2023 00:00:00

Man erhält also 01/2022 statt 12/2022 bzw. 01/2023?
Zumindest würde das einige Merkwürdigkeiten im Logfile erklären.

Danke

Servus,

hab keine Ahnung was Du da genau vorhast, aber egal was Dein Problem ist...die eine Sekunde im Jahr wirds nicht sein.

Ich rate mal ins Blaue: Batterie schwach?

Es ist nicht eine Sekunde im Jahr es könnte bei jedem "Sprung auf 0" (also beim Wirksamwerden des Übertrag auf die nächstgrößere Zeiteinheit) passieren. Könnte also auch jede Sekunde einmal passieren wenn man Sekunden und Millisekunden ausliest.

Es ist nicht eine Sekunde, um die es geht, sondern im Extremfall ein volles Jahr, um den die Zeit falsch wird, wenn man die einzelnen Bestandteile (unabsichtlich) teilweise vor und teilweise nach einem Übertrag liest.
Oder auch folgendes schönes Beispiel:
Es ist der 31. Januar 23:59:59
Jetzt liest du die Sekunden (59), die Minuten (59), die Stunden (23), den Tag(31). Dann springt die Zeit 1 Sekunde weiter und du liest den Monat. Damit hast du als Datum / Uhrzeit den 31. Februar 23:59:59.
In diesem Fall würde man sagen können, das es gleichgültig ist, ob man den 31. Januar 23:59:59 oder den 1. Februar 00:00:00 liest. Aber wenn man Pech, hat liegt man eben einen Monat daneben. Ganz analog hat man das gleiche Problem auch bei Fehlern um einen Tag, eine Stunde usw.
Auch das Lesen der einzelnen Komponenten in anderer Reihenfolge ändert an diesem Problem nichts. Lösen könnte man das Problem nur, wenn man die gesamte Zeit lesen könnte, ohne dass dieser Lesevorgang von einem neuen Takt der Uhr unterbrochen wird.
Ich habe in der Doku keine Möglichkeit gefunden, das Problem sauber zu lösen.
Das hat mit einer leeren Batterie nichts zu tun.

Der Beitrag wurde von CNCFr bearbeitet: 13.02.2023, 21:39 Uhr

Das Ergebnis sollte doch stimmen, wenn

- man alle interessierenden Werte ein zweites Mal liest
- beide 'Messungen' in allen Werten dasselbe Ergebnis liefern
- und alle Auswertungen innerhalb eines hinreichend kleinen Zeitraums abgeschlossen wurden

oder?

Das ist sicher richtig.
Es bedeutet aber, dass du im Fehlerfall den Lesevorgang solange wiederholen musst, bis du zwei mal die gleichen Werte hintereinander gelesen hast. Damit ist man auf der sicheren Seite.
Es könnte allerdings auch sein, dass bei einem Wertepaar, die zweite Zeit z.B. nur eine zwei Millisekunden später liegt als die erste, ohne dass in der Zwischenzeit ein Übertrag statt gefunden hat. Dann wären eigentlich beide Zeiten OK.
Man kann natürlich auch aus einem "Falschen" paar mit entsprechendem Aufwand die richtige Zeit ermitteln.
Wenn man im Abstand von z,B. < 1 Sekunde zwei Zeiten liest, und die zweite Zeit ist praktisch genau ein Jahr oder auch nur eine Stunde später als die erste, weiß man schließlich auch, was da passiert ist.

Sich im Einzelnen zusammen zu reimen und zu analysieren, wann meine eine gelesen Zeit akzeptieren kann und wann man sie verwerfen muss, ist schon ziemlich grotesk.

Korrekt wäre es, wenn die Steuerung intern den Wert in einer einzigen (atomaren) Operation lesen und irgendwo abspeichern würde, wo man sich die einzelnen Werte dann z.B. in einem Array mit beliebiger Verzögerung abholen könnte.