PDA

Vollständige Version anzeigen : Gibt es ein Milliarden-Sekunden-Problem


Kurt aus Kienitz
03.09.2001, 12:38
Hallo miteinander,

Mir liegt eine Anfrage vor, in der die Befürchtung geäußert wird, UNIX könnte ein Problem mit Milliarden Sekunden haben.
D.h. die Anzahl der Sekunden könnte von 999.999.999 nicht auf 1.000.000.000 umspringen sondern auf -1 oder so ;)

Ich habe daß mal berechnet.

Wenn man auf den 01.01.1970 eine Milliarde Sekunden (11.574 Tage) addiert, kommt
09.09.2001 heraus.

Da die Sekunden aber sicherlich in 32 Bit dargestellt/gespeichert werden, kann man dort
4.294.967.296 Sekunden speichern. Das sind 49.710 Tage und damit landet man beim
07.02.2106 und das stört mich nur ein ganz kleines bisserl :)

Nun stellen sich folgende Fragen:

Berechne ich das richtig ?

Hat von euch schon jemand von diesem "Problem" gehört, gibt es das überhaupt ?

Vielen Dank im voraus.

Nockenwelle
03.09.2001, 21:52
Hallo Kurt,

ja, das Problem gibt es. Soweit ich weiß sind fast alle UNIX-Derivate davon betroffen.
Das erste Bit des Sekundenzählers ist meines Wissens das Vorzeichen und wird bei den derzeitigen Systemen nicht zu nutzen sein. Also sind es dann ca. 2 hoch 31 Sekunden. Die Umstellung darauf dass es prinzipiell als positive Zahl gilt, wird aber kein so großes Problem darstellen, hoffe ich. Wenn dies jetzt akut wäre, wäre das doch DER Hype, Patches herauszubringen.
Evtl. wirst du irgendwann mal Dateien finden, die 1951 erzeugt wurden-dann weißt du, dass da was falsch gelaufen ist ;)
Ein bisserl mehr Zeit haben wir schon noch.
Ich hab' da was vom Jahr 2032 im Ohr, kann mich aber täuschen.

Datenbanken haben das gleiche Problem. Soweit mir bekannt ist das höchste Datum eine Ingres Datenbank ca. im Jahr 2360. Access kann 9999, Oracle etwas über 2400.
Probleme hatte ich schon bei Java-Anwendungen, die sich nicht entscheiden konnten, welches Jahrhundert wir haben. So wurde aus der Angabe 01.01.96 das Datum 01.01.1596(manchmal auch 01.06.1096). Dies ist auch wiederum ein Datum, daß eine Datenbank nicht umbedingt darstellen kann-> Die Anwendung stüzt dir ab. Dies war aber eher ein Programmierfehler.
In der c't stand da mal was Grundsätzlich zur Datumsberechnung vor allem mit sehr kleinen und sehr Großen Datumsangaben(der Artikel müsste aus 97 oder 98 stammen).

Mal 'ne andere Frage. Wir haben in einer Anwendung das Problem einer 'Wanderniere'- Das heißt bei der Umstellung von Sommer- auf Winterzeit ändert sich die Anzeige auf den Vortag. Beispiel: Man speichert ein Datum-es wird mit dem 23.11.00 0:00:00 Uhr gespeichert. Angezeigt wird aber der 22.11.00 23:00:00 Uhr.
Das Problem ist wohl, das einige UNIX-Varianten, die Sommerzeit nicht kennen und die DB das nicht jedesmal neu errechnet, WINNT aber schon und die Synchronisation zum Server automatisch von statten geht.
Kennt jemand so etwas?

Cu

Kurt aus Kienitz
04.09.2001, 09:14
Hallo,

Vielen Dank für deine Antwort.
Das Vorzeichen hatte ich natürlich völlig außer Acht gelassen.

Nach meinen neusten Berechnungen (24.855 Tage) landet man nun beim 19.01.2038.
Bis dahin ist unser Wartungsvertrag abgelaufen :D

Das Problem mit der Umstellung von Sommer- auf Winterzeit kenne ich so leider nicht :(
Wir hatten allerdings beim Zusammenspiel von Lotus Notes und Windows NT das Problem das beide meinten "jetzt stell ich mich mal auf Sommerzeit um" und schwups gingen bei uns alle Uhren zwei Stunden vor/nach.
U.u. ist daß bei dir ja auch so ein Zusammenspiel.

Nockenwelle
04.09.2001, 23:26
Hallo Kurt,

das sind wahrscheinlich so die Feinheiten von: Ingres.
Das Problem ist einfach sch*****.
Bei jeder Speicherung setzt das(Windows)Programm die Uhrzeit wieder auf 0:00:00
D.h. Ich hab' ein 'Gültlig von'-Datum, nur wird es immer älter, weil es sich jeweils um einen Tag versetzt. Aus der Stunde Verzug,was schon schlimm genug ist, werden dann 24 Stunden, dann 25 Stunden dann 48 usw.

Diese Daten dürfen sich nicht ändern, weil eben darauf Fristen mit erheblichen rechtlichen Konsequenzenzen darauf beruhen.

Es ist nicht die erste Klamotte, di ich mit dem System erlebe. Es beruhigt mich nur, dass sämtliche Auftragnehmer darauf auch schon reingefallen sind. Die meisten Sachen haben wir jetzt im Griff, aber dieses hier...

Cu