Liebe Community,

ich sollte folgendes Problem lösen:

Ich benötige ein Programm, das bei der Initialisierung die aktuelle Zeit als UTC speichert. Die Zeit soll anschließend beliebig änderbar sein, in dem eine neue Zeit als UTC von einem externen Programm gesetzt wird. Die geänderte Zeit soll wiederum als UTC gelesen werden können.

Der aktuelle Code (vereinfacht):

Mit diesem Code lese ich leider nicht, was geschrieben wurde. Es gehen einige Stunden verloren. Findet jemand den Fehler?

Anmerkung: Die zwischen dem Schreiben und Lesen vergangene Zeit habe ich zur Vereinfachung weggelassen. Das ist jedenfalls nicht die Ursache für den "Zeitverlust".

Ich kann leider nichts konkretes zu Deinem Code-Problem beitragen, aber ich hoffe Dir ist bewusst, dass es äußerst schwierig ist Funktionen für Zeit und Datum selber zu programmieren. Wo immer möglich, sollte man die Systemroutinen verwenden, da viele Sonderfälle auftreten, mit denen man nicht rechnet:

time(), mktime(), gmtime() und difftime() sind Systemroutinen. Es geht lediglich darum, die aktuelle Zeit mit einer einstellbaren Zeitdifferenz auszugeben.

Ich habe gerade bemerkt, dass sich ein Fehler in time_write() eingeschlichen hat (difftime fehlt), den ich im Ausgangspost nicht mehr korrigieren kann. Hier die korrekte Fassung:

Ja, aber so „low-level“, dass vermutlich einige der Problemfälle dort noch gar nicht behandelt werden?
Je nachdem wofür du deine einstellbare Zeitdifferenz verwendest, können durchaus einige der im Link angesprochenen Probleme auftreten!

Hast du da vielleicht auch ein Minimalbeispiel damit man sieht wie die Funktionen verwendet werden?

Ein in einem Simulator laufendes Betriebssystem liest die Zeit (time_read). Wenn man im Gastsystem die Zeit umstellt, wird die neue Zeit geschrieben (time_write). Diese neue Zeit sollte vom Gastsystem auch wieder korrekt ausgelesen werden können. Das Gastsystem schreibt UTC und erwartet beim Lesen ebenfalls UTC.

Minimalbeispiel:
Wie sieht der Source-Code für ein einfaches Beispiel aus, bei dem der Fehler auftritt.

Hmm mktime() liefert dir die lokale Zeit und nicht UTC. Stackoverflow sagt timegm() wandelt eine tm Struktur in ein time_t UTC um.

Mir ist allerdings nicht ganz klar wozu du den Offset brauchst. Laut deiner initialen Beschreibung sollte es doch reichen die Startzeitvariable jedes Mal beim Schreiben mit der neuen Zeit in time_t zu überschreiben, oder?

Und noch was grundsätzliches zur Programmierung:
Wie Dirk schon geschrieben hat, die Programmierung mit ZeitInfos ist nicht so ganz trivial. So ist zum Beispiel der schreibende Zugriff auf Elemente der struct tm definitiv verboten. So ein Statement wie t.tm_hour++; ist einfach verboten, denn man müßte da ja auf einen "Überlauf" der Stundeninfo reagieren, die dann auch auf "höhere Zeitelemente" durchschlagen kann.

Ich würde die Sache mal so angehen, dass ich die Manipulationen immer mit den time_t machen und die dann wieder in eine struct tm umwandeln.

Wenn ich es richtig verstehe, führt mktime() keine Umrechnung der Zeit durch. Setze ich die Werte in der tm Struktur also auf meine Lokalzeit, ist die resultierende time_t ebenfalls Lokalzeit. Nachdem das Gastsystem aber UTC liefert, müsste dann auch die resultierende time_t UTC sein, oder irre ich mich da?


Du hast recht. Im obigen Beispiel wäre diese Vereinfachung möglich. Ich sehe mir das große Programm einmal an und prüfe, ob dort auch auf den Offset verzichtet werden könnte oder ob es für Auswertungen oder Ähnliches zum Einsatz kommt. Allerdings sehe ich keinen Zusammenhang mit meinem Problem.

Das ist nur ein Beispiel zur Veranschaulichung. Das Gastsystem setzt die Werte im Simulator natürlich korrekt.

Ich benutze das Zeitgeraffel zu selten um ein echter Experte zu sein, aber ich interpretiere die Beschreibung von mtkime so dass die Zeitzone und Sommerzeit berücksichtigt werden. Selbst wenn auf dem System GMT als Zeitzone gewählt ist hast du immer noch das Sommer/Winterzeitproblem.
Sei es drum es gibt ja wie oben erwähnt eine Methode (timegm() als inverse Methode zu gmtime() die du ja schon verwendest), die das alles ignoriert und UTC annimmt. Ist die Zeit damit korrekt?

Prinzipiell bin ich bei pstoehr, ich würde intern wo möglich mit time_t arbeiten und nur bei der Ausgabe in ein anderes Format umwandeln.

Ich werde das am Abend testen und dann eine Rückmeldung geben. Allerdings scheint timegm() nicht ideal zu sein, was Portierbarkeit betrifft. Das müsste daher plattformabhängig noch implementiert werden (wofür es aber wohl fertige Lösungen gibt).
Die Umwandlung von und zu tm ist deshalb erforderlich, weil das simulierte System eine Real Time Clock verwendet, die in ihren Registern Sekunden, Minuten, Stunden, Monatstage, Monate und Jahre ab 1900 zählt. Daher bekomme ich vom Gastsystem die Zeit in dieser Form geliefert.

Apples Dokumentation sagt da genau das Gegenteil:

Danke für Rückmeldung! Dann ist das wahrscheinlich der Fehler. Ich werde es wie gesagt später testen und mich mit dem Resultat melden.

Ich kann bestätigen: mktime() timegm() löst das Problem.

Vielen Dank für alle konstruktiven Beiträge!