![](https://seccdn.libravatar.org/avatar/91258aa3ce703520a02a4c8aef955eb4.jpg?s=120&d=mm&r=g)
On 04-Jan-00 Stephan Beyer wrote:
Dazu werden bisher vorzeichenbehaftete 32-Bit-Zahlen genutzt -- zu dem genannten Zeitpunkt ist bei denen Schluss. Haette man statt dessen z.B. einen 64-Bit-Zaehler, waere erstmal fuer die naechsten knapp 300 Milliarden Jahre Ruhe. Wartum eigentlich nicht. Sind ja schliesslich letztendlich nur 64 1en bzw 0en, also 8 Byte --- wenn ich von den ganzen Zeugs mehr Ahnung hätte, würde ich intelligentere Sätze loslassen...
Weil 32 Bit zu der Zeit, als Unix konstruiert wurde, die übliche Wortlänge der benutzten (damals noch recht "großen") Maschinen war. Das heißt, 32 Bit war die Breite, die die Hardware optimal schnell verarbeiten konnte. Und Speicherplatz war auch noch nicht so wertlos wie heute (binäre Darstellungen sind diesbezüglich effizienter als z.B. BCD-Codierung).
In 38 Jahren werden 64-Bit-Maschinen laengst ueberholt sein, der Zaehler wird lange vorher vergroessert und alle Programme werden bis dahin etliche Male neu kompiliert worden sein (schon allein wegen neuer Prozessoren).
In 38 Jahren ist es aber schon zu spät.... Nur was passiert, wenn die Zahl erreicht ist? Abstürzen garantiert nicht. Es ist geradezu absurd, dass alles nur wegen der Zeit hängren bleibt. Bei mir falle ich immmer wieder aufs alte Datum zurück, dh. die Zeit bleibt stehen---
Das hängt davon ab, was mit dem Datum gemacht wird. Wird das Datum einfach nur gespeichert und wieder ausgegeben und weiß man, wie man diese Ausgabe interpretieren muß, dann ist das ja auch bei 2 Dezimalstellen kein Problem. Schwierig wird es, wenn verschiedene Datumsangaben verglichen oder Differenzen gebildet werden (dann bist Du z.B. auf einmal 100 Jahre oder auch 68 Jahre mit Mahngebühren in Verzug <g>).
Michael Schulz schrieb:
seit glibc 2.1 ist das immerhin schon ein long. Also gilt das Problem nur noch für 32bit Prozessoren. Alle 64-bittigen sind seitdem aussen vor. *heul* Ich will auch in 38 Jahren nicht auf meinen heißgeliebten 486er DX 4 mit 100 MHz verzichten :-(
Kein Problem. time_t als long long definieren und alles (Kernel, libc, Anwendungen, ...) neu compilieren.
Und ob es in 38 Jahren noch sowas gibt. Ich zweifel mal. da ist sowas antik... (Deswegen behalte ich ja meinen 8087, meine beiden 286, meinen 386 SX und meinen 486DX4) Ich bezweifle aber, das es da noch Steckplätz für diese geben wird...
Trotzdem, man kann das Problem ja auch ohne die Erweiterung des Datentyps (oder wie das in korrekter Programmierersprache heiszt) man brauch IMHO den Zähler doch nur von 1.1.2000 0:00 Uhr zählen lassen, und dann jhat sich das bei 32-Bit Systemen auch erstmal wieder rund 67 Jahre gelegt... ODer liege ich da falsch?
Dazu müßte man alle Programme, die diese Angabe interpretieren, entsprechend
verändern. Der Aufwand ist wesentlich größer, und Neucompilieren des gesamten
Systems ist genauso angesagt.
--
Erhard Schwenk