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

Christian Boltz lug-ld at cboltz.de
So Mär 15 19:03:14 CET 2020


Hallo Heinz, hallo zusammen,

Am Sonntag, 15. März 2020, 15:36:22 CET schrieb Pahle Heinz:
> 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]

Klingt richtig, wobei ich gerade nicht weiß, ob Du mit oder ohne 
Schaltsekunden gerechnet hast ;-)

Bevor ich mir die Finger wund schreibe - das Jahr 2038-Problem war vor 
Kurzem Thema im Chaosradio. Falls Du also 1 1/4 Stunden Zeit hast, hör 
Dir https://chaosradio.de/cr257-das-jahr-2038-problem an ;-)

Trotzdem noch ein paar kleine Anmerkungen:

> 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?

Mit Vorzeichen ("signed") war früher[tm] wohl sinnvoll, weil unsigned 
deutlich mehr Rechenpower benötigt hätte (Quelle: Chaosradio, siehe 
oben) und das auf der damals[tm] aktuellen Hardware wohl spürbar war.

Auf halbwegs aktuellen Systemen ist eh alles 64bit, und das hat mehr als 
genug Platz für die absehbare Zukunft ;-) (laut Wikipedia für 292 
Milliarden Jahre, sollte erstmal reichen)

Bleibt noch das Problem von IoT-Geräten mit dünner Hardware - aber dazu 
verweise ich endgültig aufs Chaosradio.

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

Damit könnten zumindest Deine Enkel oder Urenkel das nächste Problem 
erleben ;-)

Außerdem werden Timestamps auch für zukünftige Zeitpunkte hinterlegt 
(z. B. Ablauf-/Auszahlungsdatum einer Lebensversicherung) - in der 
Praxis könnte das Jahr 2038-Problem also schon deutlich vor 2038 
auftreten.


Gruß

Christian Boltz
-- 
Die Jungs von FreePascal portieren zur Zeit auf alles was
nach Prozessor aussieht oder Prozessor im Namen hat ;-)
[Gerald Goebel in suse-programming]