C++ time_t und struct tm nicht verlässlich für Jahr 2038?
Hallo, scheinbar wird 2038 time_t nicht mehr auszureichen wenn es 32bit ist. Ich bin leider auf struct tm angewiesen weil ich Wochentag, Stunde etc auslesen will. Frage 1: bis zu welchem Jahr reicht time_t bei 64bit? Frage 2: Muss bei 64bit das Programm sowie das Betriebsystem 64 Bit sein? Frage 3: Gibt es eine alternative zu struct tm, um aus der unix Zeit Tag der Woche, Stunde des Tages, etc auszulesen? Danke schon mal!
2 Antworten
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.
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.
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?
Rechne das genau Jahr dir selber aus. Er reicht für 292 Milliarden Jahre.
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ß! :)
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.