C++ time_t und struct tm nicht verlässlich für Jahr 2038?

...komplette Frage anzeigen

3 Antworten

time_t und struct tm sollten im Bezug auf C++ nicht mehr direkt genutzt werden, also anstelle des <ctime> Headers lieber die Dinge aus dem <chrono> Header benutzen. Zumindest theoretisch, da sich <chrono> eher mit Zeitmessung, als mit einem Datum befasst:

http://www.cplusplus.com/reference/chrono/

Seit C++11 ist <chrono> die bevorzugte Methode um mit Zeiten umzugehen. Außerdem ist es portabel und dein 2038 Problem hat sich damit erledigt. :)

Aaaaaber, da es leider (noch) keinen std::date Namespace gibt, ist man immer noch auf ctime() & Co angewiesen. Eigentlich sehr unschön, wenn man sich nicht unnötig von Drittbibliotheken abhängig machen möchte.

Vermutlich ist ...

auto n = std::chrono::system_clock::now();

... das, womit du anfangen möchtest. :)

Allerdings ist time_t schon seit einiger Zeit 64 Bit breit, zumindest auf Systemen, die das unterstützen. Von daher wird dich im Jahre 2038 keine Katastrophe erwarten, vorausgesetzt, du entwickelst für aktuelle Desktop Plattformen.

(In Form von µCs wird es selbst dann natürlich sogar noch 16- oder gar 8-Bit Plattformen geben, aber dabei hast du sicherlich einen ganz anderen Schwerpunkt.)

Naja, viel Spaß! :)

Bei 64bit musst du dir keine Gedanken zu diesem Alias machen.

Ja, das Programm und das System müssen beide 64bit unterstützen, DENN das Programm läuft auf dem System und die Daten werden ausgetauscht, sei es durch dynamische Libraries oder durch einfach Adressen.

Aber: In Linux gibt es auch 64bit.daten unter 32bit-Systemen.

Wenn du das nicht weißt, solltest du noch mal die Grundlagen durchgehen, vermutlich hast du auf deinem Lernweg etwas sehr leichtfertig übersprungen.

Du kannst dir jederzeit alle nötigen Alternativen selber schreiben. Unter Linux wird von manchen gerne mal ein Shellaufruf verwendet und dann die Rückgabe ausgewertet. :-)

Du schreibst leider nicht einmal, was du für Systeme verwendest.

DIGGER6 22.01.2017, 23:06

Zur Zeit Windows aber in Zukunft vielleicht auch Linux. Durch struct tm bin ich eben auf time_t als Datentyp angewiesen sonst hätte ich vielleicht einfach unsigned long int oder sowas genommen aber das will struct tm nicht haben.

0
priesterlein 22.01.2017, 23:13
@DIGGER6

Tja, da 32bit-Systeme sowieso langsam ausmustern sollten, wäre es ratsam, sofern 32bit nicht zwanghaft gefordert ist, auf 64bit zu setzen. Dann werden auch in Windows die Libraries benutzt, die die Datenstrukturen mit den potentiell größeren Werten zulassen.

1
DIGGER6 22.01.2017, 23:24
@priesterlein

ok dann muss man sich eigentlich keine Sorgen machen ausserdem könnte man auch ein exception handling machen. Bis zu welchem Jahr geht denn das 64bit time_t?

0
priesterlein 22.01.2017, 23:27
@DIGGER6

Rechne das genau Jahr dir selber aus. Er reicht für 292 Milliarden Jahre.

1

Ich denke, das ist zu umfangreich für "gutefrage".  Google z.B. nach "2038 bug"    

Guck Wikipedia Jahr-2038-Problem  für das Allgemeine

Guck hier, da steht eine Lösung, vielleicht ist es auch deine:
http://stackoverflow.com/questions/7914368/64-bit-unix-timestamp-conversion

Es geht um die Anzahl von Sekunden die man in einem 31/32 Bit Register zählen kann. Das sind ca. 68 Jahre. Mit der Basis 1970 ergibt das 2038. Ein Bit mehr ( aus  einem 64 Bit Register )  bedeutet 68 * 2,  2 Bit mehr bedeuten 68 *4 usw. Wenn ich mich nicht verrechnet habe, kann man zusammen mit den oberen 32 Bit aus einem 64 Bit Register länger Zählen als das Sonnensystem voraussichtlich lebt. 

Ob alle 32 Bit Betriebssysteme damit umgehen können, weiß ich nicht. Das hängt sicher an der Hardware und vielleicht vom Kernel ab, denkbar ist es. 

Was möchtest Du wissen?