Michael Schulz wrote:

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. Und ob es in 38 Jahren noch sowas gibt. Ich zweifel mal. Wer zweifelt mit?

Ich nicht ;-) Wenn wir eins aus dem Y2k-Problem gelernt haben dann das, daß man sich nicht darauf verlassen soll, daß sich die Probleme von selbst lösen. Das Problem hat IMHO nichts mit der Bitbreite der CPU zu tun (zB die 32Bit-CPU Intel Pentium mit MMX hat 64 Bit, MMX eben), sondern ist lediglich ein Problem, der darstellung im Speicher. Sobald Zeitpunkte in Datenbständen (also nicht Programme, sondern Nutzdaten) als 32Bit-Werte (in sec seit 1.1.1970) abgelegt sind, kann es zu Problemen kommen. Dieses Problem ist überschaubar und in 38 Jahren sicherlich leicht zu lösen. Gruß Raphael Becker -- Online-Doku: http://home.pages.de/~online-doku Gesucht - Gefunden: Linux-Anleitungen Fehlt was? Dann nix wie her mit dem URL mailto:online-doku@gmx.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Raphael Becker schrieb am 04.01.2000 um 13:01:39 +0100: Hallo Raphael,

Michael Schulz wrote:

...

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. Und ob es in 38 Jahren noch sowas gibt. Ich zweifel mal. Wer zweifelt mit?

Ich nicht ;-)

Wenn wir eins aus dem Y2k-Problem gelernt haben dann das, daß man sich nicht darauf verlassen soll, daß sich die Probleme von selbst lösen.

Das Problem hat IMHO nichts mit der Bitbreite der CPU zu tun (zB die 32Bit-CPU Intel Pentium mit MMX hat 64 Bit, MMX eben), sondern ist lediglich ein Problem, der darstellung im Speicher.

Vielleicht falsch ausgedrückt. main() { printf("%d %d\n",sizeof(int),sizeof(long int)); } ergibt auf Intel: 4 4 ergibt auf Alpha: 4 8 Bis denne, Michael -- B: Now we're getting somewhere. BH: It's like you can say what you want about Maiden, but when it comes to making videos they don't screw around. (Beavis and Butthead about Iron Maiden Fear of the Dark: 'From here to eternity') --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Stephan Beyer wrote:

Hi,

Eilert schrieb:

...

Das Problem liegt ja darin, dass in Linux bzw. Unix die Zeit intern in Sekunden seit dem 01.01.1970, 0.00 Uhr gezaehlt wird.

Ich dachte erst MIllisekunden...

Tja, so kann man sich täuschen. Mit Millisekunden hätte der Spaß ganze 24 Tage 20 Stunden und knapp 32 Minuten gehalten ...

...

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

...

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

Naja, zwei Wochen haben wir dann noch Zeit ;-)

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--- Nun ja, meinst Du mit Abstürzen den ganzen Rechner oder nur Anwendungen?

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 :-( Mußt Du ja auch nicht. Du must nur dafür sorgen, daß die Zeiten intern in längeren Variablen abgespeichert werden.

...

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

Hans Klein:

...

PS: wenn der Thread OT wird sagts einer ;-) Vermutlich in 38 Jahren ;-)

Glaub, das isser...

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? Das würde aber gleichzeitig bedeuten, daß Du die Zeiten auch umrechnen mußt. Es reicht also nicht, einfach nur einen Datentypwechsel durchzuführen, der IMHO schneller ablaufen dürfte (insbesondere von int nach long). Außerdem must Du dann auch die Berechnung des Datum umstellen. Die müßte man jedoch unangetastet lassen können, wenn nur der Datentyp geändert wird.

-- Heiner Lamprecht Philosophenweg 79 D - 72076 Tuebingen email: heiner@kijumfo.de http://www.kijumfo.de GnuKontor: http://agenda21.ggi.uni-tuebingen.de/heiner/gk/ KFLog: http://agenda21.ggi.uni-tuebingen.de/heiner/kflog/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com