nicht angemeldet
2038, und zwar IIRC Anfang Januar. Das dürfte aber kein Problem sein, weil man bei Linux "nur mal eben schnell" die Zeit 64Bit statt 32Bit kodieren und den Kernel neu kompilieren muß.
Hi,
das dachte ich auch mal und hatte deswegen mal in de.alt.jahr2000 nachgefragt, aber anscheinend ist das Problem doch noch etwas komplexer:
----schnipp----
Juergen Ernst Guenther schrieb am 14 Mar 1999 23:30:53 GMT:
xs.bion@ndh.net (Stefan) writes:
Deshalb ist der 7.2.2036 6:28:15 GMT tragischer.
Ab dann wird naemlich das timed-Protokoll die
Hufe streichen, das uebertraegt naemlich nicht
die Zeit seit EPOCH, sondern die Zeit seit
1.1.1900 00:00:00 als unsigned 32-bit-Integer.wie gesagt (gestriges Posting), das gilt eben nur für 32-Bit-Integer.
Aber ob man in 32 Jahren noch mit 32 Bits rechnet??Wenn die Werte in C z.B. einfach nur als
int sekunden;
definiert wurden, müßte doch ein einfaches Recompilieren mit einem
64-Bit-Compiler unter einem 64-Bit-Betriebssystem ausreichen, um diese
Problematik zu lösen, oder sehe ich das falsch?Ja. Das siehst du falsch.
Das timed-Protokoll uebertraegt nur 32 bit.
Das ist _kein_ Kernel-Interna. Wuerde man es einfach
mit 64 bit kompilieren, wuerde es nicht mehr funktionieren,
da keine Gegenstellen da waeren, die das verstuenden.
Es ist in diesem Falle eben _kein_ interner Wert, sondern
eine Protokolldefinition.In 30 Jahren werden wir das Problem haben, dass es da
n verschiedene Ansaetze gibt, die teilweise sofort,
teilweise nach dem 7. 2. 2036 inkompatibel sind.Meine Hoffnungen liegen bei NTP/SNTP. Das ist zwar
wesentlich komplexer als timed, und fuer beispielsweise
diskless Workstations voellig ueberzogen, aber wenigstens
bis 2038 ok. FYI: Hier werden 64-bit-Werte uebertragen,
aber nur die obersten 32 Bit koennen Sekunden zugeordnet
werden. Wenn wir Glueck haben, sind sie uint, und damit
zumindest bis 2106 zuzuordnen..m.
Juergen Ernst Guenther
This news-posting has been powered by vi.
----schnapp----
Gruß,
Stefan