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

<center>

<HR>

</center>

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

Hi Henning,

der 64bit Integer löst nur das Problem des 32bit-Überlaufs im Jahre 2038, aber nicht das Problem der mißbrauchten Bits!
Wer die Bits 1 und 2 des 32bit-Integers ausliest bzw. manipuliert, shiftet den Integer um 30 bits nach rechts. Ein 64bit Integer schafft hier keine Abhilfe, so dass reine Neukompilation oder ein moderneres Unix keinen Effekt haben.

Zur Dimension des Problems:
Es reicht ja, wenns an den entscheidenden Stellen kracht, und wenn es auch nur in 1 Promille aller Softwaresysteme so gemacht wurde. Die Folgen sind jedenfalls ausreichend dramatisch angesichts der Größe des Zeitsprungs.

Zumal könnte der Fehler schwieriger zu entdecken sein, da nicht genau um Zehnerpotenzen an Jahren zurückgesprungen wird, sondern um einen"krummen" Wert. Zudem tritt der Fehler nicht generell auf (wie beim Millennium-Bug), sondern nur wenn das Bit 31 mit 0 überschrieben wird, was je nach Verwendungsart dieses Bits ein seltener, aber möglicher Fall sein könnte.

Außerdem bestehen in dieser Hinsicht kaum Erfahrungen, zumal der letzte 29bit Überlauf 1987 war und Software, welche dieses Bit mißbrauchen könnte, weit vor 1987 geschrieben sein müßte. Dieser 32bit-Time-Integer zählt aber erst seit Jan.1970. Weiterhin könnte relevant sein, dass 30 bits als runde Zahl einfach attraktiv zur Datumskodierung ist, jedenfalls eher als 29.

Ich würde das nicht aus den Augen verlieren, zumal im Gegensatz zum Millennium-Bug hier keinerlei Aufmerksamkeit (=Wartungsaufwand) besteht.

Und wir wissen ja: womit man am wenigsten rechnete, das...



<center>

<HR>

</center>

>Hi Henning,
>der 64bit Integer löst nur das Problem des 32bit-Überlaufs im Jahre 2038, aber nicht das Problem der mißbrauchten Bits!
>Wer die Bits 1 und 2 des 32bit-Integers ausliest bzw. manipuliert, shiftet den Integer um 30 bits nach rechts. Ein 64bit Integer schafft hier keine Abhilfe, so dass reine Neukompilation oder ein moderneres Unix keinen Effekt haben.

Aeh - nicht unbedingt - man kann ja auch - links ins Carry Flag schieben (je
nachdem wie nun das System geartet ist).

>Zur Dimension des Problems:
>Es reicht ja, wenns an den entscheidenden Stellen kracht, und wenn es auch nur in 1 Promille aller Softwaresysteme so gemacht wurde. Die Folgen sind jedenfalls ausreichend dramatisch angesichts der Größe des Zeitsprungs.
>Zumal könnte der Fehler schwieriger zu entdecken sein, da nicht genau um Zehnerpotenzen an Jahren zurückgesprungen wird, sondern um einen"krummen" Wert. Zudem tritt der Fehler nicht generell auf (wie beim Millennium-Bug), sondern nur wenn das Bit 31 mit 0 überschrieben wird, was je nach Verwendungsart dieses Bits ein seltener, aber möglicher Fall sein könnte.
>Außerdem bestehen in dieser Hinsicht kaum Erfahrungen, zumal der letzte 29bit Überlauf 1987 war und Software, welche dieses Bit mißbrauchen könnte, weit vor 1987 geschrieben sein müßte. Dieser 32bit-Time-Integer zählt aber erst seit Jan.1970. Weiterhin könnte relevant sein, dass 30 bits als runde Zahl einfach attraktiv zur Datumskodierung ist, jedenfalls eher als 29.
>Ich würde das nicht aus den Augen verlieren, zumal im Gegensatz zum Millennium-Bug hier keinerlei Aufmerksamkeit (=Wartungsaufwand) besteht.
>Und wir wissen ja: womit man am wenigsten rechnete, das...

Das ist sicherlich richtig - aber das sollte derart selten auftreten - ne also
da ist ne uninitalisierte Variable in Atomkraftwerkssoftware richtig
wahrscheinlich gegen...

Wegen 2-Bit hat man schon zig Jahre mehr keine Klimzuege gemacht - beim Jahr
2000 Problem ging es meist um ganze Bytes (weil viele ASCII benutzen) und
nicht um 2 Popelige BITs. Man muss sich auch ueberlegen wieviel Speicher ein
Programm mehr brauch um diese 2 Bits zu nutzen. Hoechstens wenn man Daten
ueber ein sehr enges Medium verschickt (Sateliten Kommunikation vieleicht).
Aber selbst da glaub ich nicht dran.

CU
Henning



<center>

<HR>

</center>

>Aeh - nicht unbedingt - man kann ja auch - links ins Carry Flag schieben (je
>nachdem wie nun das System geartet ist).

ja man kann, aber machte man? In der Regel blendet man die 30 ersten Bits aus, schiebt nach rechts, modifiziert die beiden Bits, schiebt nach links, blendet die 30 Bits wieder rein... und hat den Salat.

Außerdem: Falls man einen kompletten (korrekten) 32bit-Time-Integer mit einem proprietären 32bit (der mit den 2 eigenen Bits) mischt, kann man sich auch sein eigenes Bit (Nr.31) verhunzen: Hat man da 0 stehen, machen OR/XOR dieses zu 1 und bewirken keinen Zeitsprung, aber womöglich irgendetwas ganz anderes. Hat man in Bit 31 eine 1 stehen, so bewirkt ein XOR (ergibt 0) nicht nur eine falsche Zeit, sondern kippt auch das eigene Bit Nr.31 in eine 0.

Es hängt also alles von der eigenen Arithmetik ab, und hier sind die Varianten und Möglichkeiten der Weiterpropagation eines Fehlers grenzenlos.

>aber das sollte derart selten auftreten - ne also
>da ist ne uninitalisierte Variable in Atomkraftwerkssoftware richtig
>wahrscheinlich gegen...

Nur merkt man den mit der uninit. Variable halt sofort bzw. nach gewisser Zeit.
Und er tritt auch nur in einer spez.Software auf. Probleme mit solchen Datumsmaßen, die in jeder Software verwendet werden, sind dank absoluter Synchronität mE viel explosiver.

>Wegen 2-Bit hat man schon zig Jahre mehr keine Klimzuege gemacht

Es reicht schon, die 2 Bits aus praktischen Gründen zu verwenden, nicht aus Platzgründen. Schließlich werden die 2 Bits bei jedem Schreiben mitarchiviert.

>2000 Problem ging es meist um ganze Bytes (weil viele ASCII benutzen) und
>nicht um 2 Popelige BITs.

...weswegen der Fehler auch besser identifizierbar war.

CU


<center>

<HR>

</center>

Hi!

Es wird bald alles besser und es können ein Haufen Ressourcen eingespart werden.
Da kümmert sich niemand mehr um die paar Bits... ;)

Ein neuer"Zero Space Tuner mit Binärbeschleunigung"! *g*

Cya
Condor

-------------------- Meldung ------------------------

Zauberkompressor oder Kompressorzauber...

Glaubt man den Behauptungen des Startup-Unternehmens ZeoSync, lassen sich Daten bald zigmal stärker komprimieren als Theoretiker bislang für möglich hielten. Sollten sich die von dem Unternehmen verlautbarten Versuchsergebnisse praktisch umsetzen lassen, versprechen sich die Forscher nicht nur eine bessere Ausnutzung von Speicherkapazitäten, sondern auch drastische Kosteneinsparungen im Internet -- etwa, wenn schmalbandigen Übertragungskanäle künftig ausreichen, um hoch komprimierte Filme in Echtzeit zu empfangen.

In Zusammenarbeit mit nicht genannten Fachleuten der Harvard University, des MIT, der Stanford University sowie Wissenschaftlern aus Warschau, Moskau, Peking und Nangking will das Zeosync-Team ein Verfahren entwickelt haben, das in Laborversuchen Zufalls-Datensätze von jeweils einigen Hundert Bit komprimieren und wiederherstellen kann. Das so genannte Relational Differentiation Encoding soll dabei die bislang allgemein akzeptierten theoretischen Obergrenzen für verlustfreie Datenkompression weit hinter sich lassen.

Gemäß dem 1948 veröffentlichten Shannon-Theorem lassen sich Informationen nur bis zu einem theoretisch vorgegebenen Ausmaß verlustfrei komprimieren und auf einem Übertragungsmedium mit vorgegebener Übertragungsbandbreite auch nur mit einer berechenbaren Höchstgeschwindigkeit weiterleiten. Shannons Überlegungen werden in der Informatik allgemein akzeptiert und trugen dazu bei, dass ihr Verfasser als einer der bedeutendsten Wissenschaftler des zwanzigsten Jahrhunderts gilt.

ZeoSyncs Mitteilungen wollen nun darauf hinweisen, dass sich Datensätze, die laut Shannon etwa um einen Faktor zehn komprimierbar sein sollten, stattdessen ohne praktisch bedeutsame Verluste um das Vielhundertfache verdichten lassen. Das Unternehmen will den so genannten Zero Space Tuner mit Binärbeschleunigung, der auf Prinzipien klassischer Physik, statistischer Mechanik und Quantentheorie beruhen soll, im Jahr 2003 auf den Markt bringen und verhandelt zurzeit nach eigenen Worten mit Chipherstellern und einem Filmproduzenten aus Hollywood über strategische Partnerschaften.

An Hand der Grundlagen, die ZeoSync zur Erklärung seiner Errungenschaften ins Feld führt, lässt sich bislang jedoch nicht beurteilen, ob es sich dabei tatsächlich um den proklamierten Durchbruch oder eher um einen schlechten Scherz handelt. Aber auch wenn Erfolgsmeldungen dieses Schlages bereits in einem diesbezüglichen Internet-FAQ Einzug gehalten haben, dürfte ZeoSync nicht zuletzt dank Fachpublikationen wie dem IEEE Spectrum Online oder Webverzeichnissen wie Yahoo ein reges Echo gewiss sein. (hps/c't)

Meldung vom 10.01.2002
<ul> ~ Quelle</ul>
<center>

<HR>

</center>

und ehrlich gesagt ein bischen nach simplen Betrug.

Wenn ich da lese,"Zufallsdatensätze" (was heisst das? Zufall?) von einigen hundert Bits um das vielhundertfache"ohne praktisch bedeutsamen Verlust" reduziert.??? Was heisst das 500 Bit auf 2 Bit oder wie?

Um ehrlich zu sein, würde das fast alle informationstechnischen, physikalischen und was weiss ich für Grundsätze auf den Kopf stellen, und sowas will ich denn schriftlich in 3 facher Ausfertigung haben:)

Gruss Juergen


>Hi!
>Es wird bald alles besser und es können ein Haufen Ressourcen eingespart werden.
>Da kümmert sich niemand mehr um die paar Bits... ;)
>Ein neuer"Zero Space Tuner mit Binärbeschleunigung"! *g*
>Cya
>Condor
>-------------------- Meldung ------------------------
>Zauberkompressor oder Kompressorzauber...
>Glaubt man den Behauptungen des Startup-Unternehmens ZeoSync, lassen sich Daten bald zigmal stärker komprimieren als Theoretiker bislang für möglich hielten. Sollten sich die von dem Unternehmen verlautbarten Versuchsergebnisse praktisch umsetzen lassen, versprechen sich die Forscher nicht nur eine bessere Ausnutzung von Speicherkapazitäten, sondern auch drastische Kosteneinsparungen im Internet -- etwa, wenn schmalbandigen Übertragungskanäle künftig ausreichen, um hoch komprimierte Filme in Echtzeit zu empfangen.
>In Zusammenarbeit mit nicht genannten Fachleuten der Harvard University, des MIT, der Stanford University sowie Wissenschaftlern aus Warschau, Moskau, Peking und Nangking will das Zeosync-Team ein Verfahren entwickelt haben, das in Laborversuchen Zufalls-Datensätze von jeweils einigen Hundert Bit komprimieren und wiederherstellen kann. Das so genannte Relational Differentiation Encoding soll dabei die bislang allgemein akzeptierten theoretischen Obergrenzen für verlustfreie Datenkompression weit hinter sich lassen.
>Gemäß dem 1948 veröffentlichten Shannon-Theorem lassen sich Informationen nur bis zu einem theoretisch vorgegebenen Ausmaß verlustfrei komprimieren und auf einem Übertragungsmedium mit vorgegebener Übertragungsbandbreite auch nur mit einer berechenbaren Höchstgeschwindigkeit weiterleiten. Shannons Überlegungen werden in der Informatik allgemein akzeptiert und trugen dazu bei, dass ihr Verfasser als einer der bedeutendsten Wissenschaftler des zwanzigsten Jahrhunderts gilt.
>ZeoSyncs Mitteilungen wollen nun darauf hinweisen, dass sich Datensätze, die laut Shannon etwa um einen Faktor zehn komprimierbar sein sollten, stattdessen ohne praktisch bedeutsame Verluste um das Vielhundertfache verdichten lassen. Das Unternehmen will den so genannten Zero Space Tuner mit Binärbeschleunigung, der auf Prinzipien klassischer Physik, statistischer Mechanik und Quantentheorie beruhen soll, im Jahr 2003 auf den Markt bringen und verhandelt zurzeit nach eigenen Worten mit Chipherstellern und einem Filmproduzenten aus Hollywood über strategische Partnerschaften.
>An Hand der Grundlagen, die ZeoSync zur Erklärung seiner Errungenschaften ins Feld führt, lässt sich bislang jedoch nicht beurteilen, ob es sich dabei tatsächlich um den proklamierten Durchbruch oder eher um einen schlechten Scherz handelt. Aber auch wenn Erfolgsmeldungen dieses Schlages bereits in einem diesbezüglichen Internet-FAQ Einzug gehalten haben, dürfte ZeoSync nicht zuletzt dank Fachpublikationen wie dem IEEE Spectrum Online oder Webverzeichnissen wie Yahoo ein reges Echo gewiss sein. (hps/c't)
>Meldung vom 10.01.2002


<center>

<HR>

</center>

>>Aeh - nicht unbedingt - man kann ja auch - links ins Carry Flag schieben (je
>>nachdem wie nun das System geartet ist).
>ja man kann, aber machte man? In der Regel blendet man die 30 ersten Bits aus, schiebt nach rechts, modifiziert die beiden Bits, schiebt nach links, blendet die 30 Bits wieder rein... und hat den Salat.
>Außerdem: Falls man einen kompletten (korrekten) 32bit-Time-Integer mit einem proprietären 32bit (der mit den 2 eigenen Bits) mischt, kann man sich auch sein eigenes Bit (Nr.31) verhunzen: Hat man da 0 stehen, machen OR/XOR dieses zu 1 und bewirken keinen Zeitsprung, aber womöglich irgendetwas ganz anderes. Hat man in Bit 31 eine 1 stehen, so bewirkt ein XOR (ergibt 0) nicht nur eine falsche Zeit, sondern kippt auch das eigene Bit Nr.31 in eine 0.
>Es hängt also alles von der eigenen Arithmetik ab, und hier sind die Varianten und Möglichkeiten der Weiterpropagation eines Fehlers grenzenlos.
>>aber das sollte derart selten auftreten - ne also
>>da ist ne uninitalisierte Variable in Atomkraftwerkssoftware richtig
>>wahrscheinlich gegen...
>Nur merkt man den mit der uninit. Variable halt sofort bzw. nach gewisser Zeit.
>Und er tritt auch nur in einer spez.Software auf. Probleme mit solchen Datumsmaßen, die in jeder Software verwendet werden, sind dank absoluter Synchronität mE viel explosiver.
>>Wegen 2-Bit hat man schon zig Jahre mehr keine Klimzuege gemacht
>Es reicht schon, die 2 Bits aus praktischen Gründen zu verwenden, nicht aus Platzgründen. Schließlich werden die 2 Bits bei jedem Schreiben mitarchiviert.
>>2000 Problem ging es meist um ganze Bytes (weil viele ASCII benutzen) und
>>nicht um 2 Popelige BITs.
>...weswegen der Fehler auch besser identifizierbar war.
>CU
Das wäre doch die richtige software für die Berechnung von Neurenten;-)So ein Programm das einfach die Zeit nach hinten verschiebt sucht der Riester;-)Du hast jetzt eine Marktlücke entdeckt.der Zentralcomputer der BfA läßt einfach ein paar Jährchen unter den Tisch fallen und unsere Rente wird etwas schmaler und das wars.;-)
Gruß EUKLID

<center>

<HR>

</center>