glibc hat Y2038-Unterstützung noch nicht standardmäßig aktiviert

• Nach 2038-01-09 3:14:07 UTC läuft ein 32-bit-time_t über

• Der Linux-Kernel wurde intern bereits vor einigen Jahren auf 64-bit umgestellt, und Alpine hat ab 3.13 auf 64-bit-time_t gewechselt

• GNU glibc unterstützt 64-bit-time_t zwar seit 2.34, aber der Ansatz ist technisch nicht vollständig ausgereift

• Bei musl und anderen UNIX-C-Library-Implementierungen ist time_t in neuem Code immer 64-bit, und es werden Kompatibilitäts-Stubs für bestehenden 32-bit-Code bereitgestellt

→ Dadurch ergibt sich mit der Zeit automatisch Y2038-Kompatibilität

• Microsoft geht bei msvcrt noch einen Schritt weiter und verwendet standardmäßig 64-bit-time_t; mit dem Makro _USE_32BIT_TIME_T ist weiterhin Zugriff auf die alten 32-bit-Funktionen möglich

• GNU glibc verfolgt genau den umgekehrten Ansatz wie diese beiden Varianten

→ Die Nutzung ist nur möglich, wenn sie explizit mit -D_TIME_BITS=64 angefordert wird

→ Irgendwann könnte dieser Standardwert geändert werden, aber bis heute ist das überhaupt nicht geschehen

⇨ Ähnlich muss auch -D_FILE_OFFSET_BITS=64, das für die Verarbeitung von Dateien größer als 2GiB nötig ist, noch immer explizit angegeben werden

→ Außerdem darf auf 32-bit-Systemen nicht mit -D_TIME_BITS=64 gebaut werden (das heißt, Y2038-Kompatibilität ist dort unmöglich)

[xguru]

Es sind zwar noch etwa 16 Jahre übrig, aber Linux steckt auch oft in Geräten, die über lange Zeit nicht ausgetauscht werden …