BOOST ptime geht die Zeit aus

Eigentlich dachte ich, dass die Welt etwas aus dem Jahr 2000 gelernt hat. Mit Argusaugen wurde am 1. Januar des neuen Jahrtausends beobachtet, ob die IT Welt untergeht.

Passiert ist wenig, es war eher nur die grafische Anzeige weniger Tools, die schlecht implementiert waren und deshalb versagte.
Und Unices wie Linux stellten ohnehin den Anspruch, mit Zeit keine Probleme zu haben.

Und dann taucht im Jahr 2019 folgende Erkenntnis auf: BOOST posix_time hat Probleme mit 32-bit Überlaufen im Jahr 2038 …
W.T.F. ?

In C und C++ Bibliotheken haben wir eigentlich ein Schlüsselwort, das alle solche Probleme löst, und zwar typedef.

Anstatt einer Dateneinheit einen Typen direkt zuzuordnen wie
int current_time;
nutzen wir korrekterweise:

typedef [best_fitting_type] time_type_t;
...
time_type_t current_time;

Und während es in den 80er Jahren eher typedef int32_t time_type_t; hieß, sollten wir spätestens seit den Jahr 2000 mit typedef int64_t time_type_t; arbeiten.
Die Betriebssysteme haben das meist auch brav getan (Microsoft ließ ein paar Funktionen aus Kompatibilität bestehen, führte aber entsprechend neue ein um das Problem anzugehen).

Dass jetzt aber ausgerechnet unser Heiland BOOST über 15 Jahre später noch 32 Bits in seinen Implementierungen hat, verwundete mich doch sehr.

Konkret geht es um BOOST’s posix_time, welche bis zur Version 1.66 offenbar mit 32 bit Typen implementiert war. Erst ab Version 1.67 sind entsprechende Korrekturen eingearbeitet.

Tja, nur leider hilft uns das gerade bei älteren Projekten wenig, die auf Grund von Abhängigkeiten zu älteren Compilern an Versionen vor dem Jahr 2018 gebunden sind.

Und die Aussage:

Na dann aktualisieren wir einfach auf eine neuere BOOST Version.

zeigt leider, dass BOOST alles andere als abwärts-kompatibel ist. Vieles muss dann umgeschrieben werden.

Fazit

Es gibt Möglichkeiten BOOST zu “hacken”, sprich den internen Datentypen auf int64 zu ändern. Aber wer weiß dann schon, ob nicht an anderen Stellen ein Überlauf passiert.

Ich würde daher versuchen nach Möglichkeit auf BOOST zu verzichten.
Denn seit C++11 haben wir mit std::chrono ein standardisiertes Modul, mit dem man ebenso an die POSIX-Zeit kommt:

 #include <iostream>
 #include <chrono>
 
 int main()
 {
   auto&& now = std::chrono::system_clock::now();
 
   auto&& count = now.time_since_epoch();
   auto&& seconds = std::chrono::duration_cast<std::chrono::seconds>(count);

  std::cout << "Seconds since epoch: " << seconds.count() << std::endl;

  return 0;
}

Und hier haben die Schöpfer etwas besser nachgedacht und generell int64 in der Implementierung von std::chrono::seconds und seinen Geschwistern vorgesehen.

Natürlich ist das auch hier ein Implementierungsdetail, das nicht zwangsläufig garantiert wird. 8-bit Mikrocontroller könnten hier auch weiter mit int32 ausgestattet sein … doch das ist schon noch ein bisschen was anderes als unsere PC- und Internetwelt, wo wir mit 64 Bit Prozessoren arbeiten und Gigabytes von [RAM]http://de.wikipedia.org/wiki/Random-Access_Memory) zur Verfügung haben.

Meine Meinung ist und bleibt daher:

Letztendlich gibt es KEINEN wie auch immer gearteten Grund, warum Zeiteinheiten (im allgemeinen Fall) mit weniger als 64 Bits implementiert werden sollten.

… und im GATE Projekt ist das natürlich auch so implementiert!