- 30 bit Marke der time() - Funktion - Taktiker, 14.01.2002, 14:40
- Re: 30 bit Marke der time() - Funktion - Henning, 14.01.2002, 15:08
- der 64bit Integer löst das Problem nicht - Taktiker, 14.01.2002, 15:55
- Re: der 64bit Integer löst das Problem nicht - Henning, 14.01.2002, 16:18
- (vorläufig) abschließend: - Taktiker, 14.01.2002, 16:42
- Re: (vorläufig) abschließend: - Euklid, 14.01.2002, 19:40
- (vorläufig) abschließend: - Taktiker, 14.01.2002, 16:42
- Re: der 64bit Integer löst das Problem nicht - Henning, 14.01.2002, 16:18
- der 64bit Integer löst das Problem nicht - Taktiker, 14.01.2002, 15:55
- Re: Dabei wäre es doch so einfach Bits zu sparen. - FlyingCondor, 14.01.2002, 17:36
- Klingt ziemlich abenteuerlich... - Spirit of JuergenG, 14.01.2002, 18:19
- Re: 30 bit Marke der time() - Funktion - Henning, 14.01.2002, 15:08
Re: 30 bit Marke der time() - Funktion
>Am 10.1.2004 um 13:37:04 UTC durchläuft eines der wichtigsten Zeitnormale in der Unix- und Windows-Welt, die C-Standardfunktion time(), die 30 bit-Marke.
>time() bezieht sich auf die Zahl der Sekunden seit dem 1.1.1970, 0:00:00 UTC. Hierbei bleiben allerdings die seit 1972 eingeschobenen (bislang insgesamt 21) Schaltsekunden unberücksichtigt, die notwendig waren, um die koordinierte Weltzeit mit der eiernden Erde zu synchronisieren. Insgesamt hat sich seit Beginn der präziseren Atomzeit TAI am 1.1.1958 ein Versatz von 32 Sekunden angehäuft.
>Der letzte Bitüberlauf (29bit) datiert auf Januar 1987 (und was hatten wir in 1987?), wobei die Intervalle für jeden weiteren Bitüberlauf immer größer werden. Der komplette 32bit-Integer läuft erst am 19.1.2038 über.
>Wenn man annimmt, dass einige Programmierer die ersten beiden Bits des 32bit-Integers (schon allein, weil 30 eine so schön runde Zahl ist) für eigene Zwecke genutzt haben und diese Software noch immer an vielen Stellen vor sich hin werkelt, ohne neu kompiliert (Neue Compiler, wie Version 7.0 von Microsoft ändern die Größe von time() auf 64 Bit) bzw. neu konzipiert (!!) worden zu sein, dann stehen hier lustige Effekte ins Haus:
>Wird dann Bit Nr. 31 durch proprietäre Nutzung auf 0 gesetzt, so werden wir genau 536870912 Sekunden oder 6213 Tage oder 17 Jahre zurückbefördert.
>Da sich einige dieser Programme in den nächsten Monaten mit Abläufen nach dem 10.1.2004 beschäftigen dürften, müßten Probleme hier schon vorher sichtbar werden.
>---
>Also Leute: Stellt Euch! Wer hat dergleichen schmutziges Zeug ehemals programmiert? Was ist schon der Millennium-Bug dagegen? ;-)
Ich glaube nicht das viele diese Bits Missbraucht haben - das sollte ein
deutlich kleineres Problem werden als das Jahr 2000.
Zumal viele Unix-Derivate das schon durch den Schritt nach 64 BIT erledigt
haben.
CU
Henning
<center>
<HR>
</center>

gesamter Thread: