[lug-ld] S) In Linux angeblich ominöses Jahr 2038 Problen

[Pahle Heinz]

Liebe LUGer,

eine Frage an die, die selbst compilieren.
A)
Ich las gerade eben aktuell in der c't, aber schon einmal vor vielen
Jahren ähnliches in c't, dass es nach Jahr 2000 auch ein Jahr
2038-Problem geben soll. Da ich eigene Kalenderfunktionen programmierte,
habe ich auch den genauen angesagten crash-Zeitpunkt:
Datum-Zeit-Intervall 31_Bit [1970-01-01T00:00, 2038-01-19T03:14:07]
Bei der Angabe ist das höchste Bit, das Vorzeichen, ausgelassen.

Jetzt will ich einfach nicht verstehen, warum man die blöde 32
Bit-Variable in der Bibliothek nicht einfach zu "unsigned" erklärt.
Kann das irgend jemand erklären?

Nebenbei, 32 Bit unsigned
Datum-Zeit-Intervall 32_Bit [1970-01-01T00:00, 2106-02-07T06:28:15]

B)
Die aktuelle c't erklärt das sogar mit 32 Bit Linux!!! Das war schon
einmal der Fall, als die c't vor Jahren für 64 Bit-Systeme warb. Wegen
dem ominösen Zählerüberlauf eben. Das ist totaler Quatsch und keine
Frage für mich. Denn: Schon ururalte 8 Bit-Systeme kannten ganz "lange"
Viel-Byte-Variablen.

FRAGE-FRAGE-FRAGE-FRAGE-FRAGE-FRAGE-FRAGE
Warum schafft es anscheinend die Linux-Welt vor 2038 nicht, in den
Bibliotheken eine long-Variable von signed nach unsigned umzustellen?
FRAGE-FRAGE-FRAGE-FRAGE-FRAGE-FRAGE-FRAGE

Gruß Heinz

PS:
Die Konkurrenz (JJ, eben nicht ...doof) hat ein Doppelwort für die Zeit,
was ein riesiges Zeitintervall bedeutet, mit einer Auflösung von, in
Worten, 100 Nano-Sekunden seit 1601-01-01T00:00:00. Für Interessierte:
1600 war bezüglich Schaltjahr Ausnahme der Ausnahme, also besser die
Zählung später mit 1601 beginnen.