Diskussion:Jahr-2038-Problem

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Jahr-2038-Problem“ zu besprechen.

Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen, und unterschreibe deinen Beitrag bitte mit Signatur und Zeitstempel oder --~~~~.

Hinweise

Automatische Archivierung
Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 720 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 2 Abschnitte.
Archiv-Tabelle Archiv
Zum Archiv
Wie wird ein Archiv angelegt?
Fairytale Trash Info.svg Die Löschung der Seite „Jahr-2038-Problem“ wurde ab dem 15. Dezember 2010 diskutiert. In der Folge wurde der Löschantrag entfernt. Bitte vor einem erneuten Löschantrag die damalige Diskussion beachten.

Neue Unixe haben das Problem nicht[Quelltext bearbeiten]

Wenn ich recht informiert bin ist bei den neuen Unix-Versionen, also eigentlich BSD das Problem behoben.


Sorry, das ist grundsätzlich nicht richtig.

Test mit openSuSE 13.1 (32bit):

vectra:~ # date -u -d @2147483647

Tue Jan 19 03:14:07 UTC 2038

vectra:~ # date -u -d @2147483648

date: invalid date "@2147483648"


Richtig ist, dass die neueren 64-bitter Linuxe / Unixe das Problem nicht mehr haben. (nicht signierter Beitrag von 84.168.232.217 (Diskussion) 13:46, 28. Feb. 2014 (CET))

Bei Mac OSX ist das Problem nicht mehr vorhanden, ebenso bei den BSDs. --Lightonflux (Diskussion) 01:37, 20. Dez. 2012 (CET)

Vielleicht wegen Umstellung von 32 auf 64 Bit ? Dann existiert das Problem aber auch dort weiterhin bei 32-Bit-Anwendungen. -- Gerd Fahrenhorst (Diskussion) 17:21, 21. Dez. 2012 (CET)
Und auch hier : das ist gröbster Unfug. Jede Applikation, die UNIX-Zeitstempel auf einem x86_64 System einsetzt wird keine Probleme mit dem Zeitstempel bekommen. Wenn allerdings diese Zeit noch ANDERWEITIG und FEHLERHAFT im Programm genutzt wird - dann (und nur dann) ist diese Aussage korrekt. Das dürfte aber eher selten sein weil es keinen Sinn ergibt, funktionierende Datentypen und Zeitzählungsmechanismen neu zu erfinden, dieser Fehler unterläuft vermutlich nur Anfängern und Aussenstehenden. Das bedeutet natürlich NICHT, dass das darunterliegende "Problem" (viel eher "Möglichkeit") gelöst ist - wie bereits erwähnt wird fehlerhafte Software dann ein zusätzliches Problem bekommen. Die alte Darstellung dieser MÖGLICHKEIT ist aber extrem propagandistisch und übertrieben - es wurde Zeit dass jemand diese offensichtliche Kampagne ausbremst, schon beim Y2K-"Problem" haben sich einige "Experten" unrechtmäßig daran bereichert, und wie man weiss hat sich auch damals herausgestellt dass die Anzahl d. Systeme, die tatsächlich fehlerhaft waren eher gering blieb. 95.223.17.23 18:28, 6. Apr. 2013 (CEST)
Wie in dem Artikel Unixzeit richtig dargestellt wird, geht es darum, ob die Zeit als 32-Bit-Wert oder als 64-Bit-Wert abgespeichert wird. Das hat weder etwas mit dem Prozessor noch mit dem Betriebssystem zu tun (ich kann 32-Bit Software in der Regel auch auf einem 64-Bit-Prozessor auf einem 64-Bit-Betriebssystem laufen lassen). 32-Bit Software kann auch 64-Bit-Variablen nutzen, 64-Bit Software auch 32-Bit Variablen. Somit bleibe ich bei der Behauptung, dass es ein reines Softwareproblem ist. -- Gerd Fahrenhorst (Diskussion) 18:55, 6. Apr. 2013 (CEST)
Ist ja schön dass du bei deiner "Meinung" (-> seltsame Illusion) bleibst ... vor einem erneuten Editieren solltest du dir aber die Mühe machen, zumindest diesen Artikel hier zu lesen, ansonsten würde das recht schnell zur Lachnummer werden ... ich mein ja nur - und tu dir selbst einen Gefallen stelle die Behauptung nie in der Gegenwart von Experten auf.95.223.17.23 21:09, 6. Apr. 2013 (CEST)
Wäre schön wenn du in deinen Aussagen etwas nüchterner wärst. Dass der time_t auf 64 Bit Schnittstellen anders realisiert ist als auf 32 Bit, ist ja unstrittig. Wie im Artikel im Abschnitt Abhilfe auch richtig angegeben ist, gibt es zwei Wege zur Abhilfe: 1. Prozessor, Betriebssystem und Applikationen auf 64-Bit umstellen. 2. die Anwendungen auf eine andere Zeitbasis umstellen (de facto unabhängig von Prozessor und Betriebssystem, da heute alle üblichen 32-Bit-Betriebssysteme auch eine 64-Bit Zeit anbieten). Für Weg 1 ist in der Tat ein 64-Bit Prozessor nötig - das heißt aber weder dass zur Beseitigung Jahr-2038-Problems zwingend ein 64-Bit-Prozessor nötig ist (es gibt ja auch Weg 2) noch dass mit 64-Bit-Prozessoren das Problem automatisch gelöst wäre. Von daher stört mich die derzeitige Betonung der Prozessoren im Abschnitt Hintergrund. -- Gerd Fahrenhorst (Diskussion) 23:17, 6. Apr. 2013 (CEST)
Doch, GENAU DAS BEDEUTET ES - auf einem x86-64 Prozessor KANN KEIN ÜBERLAUF STATTFINDEN - und somit IST DAS PROBLEM DAUERHAFT GELÖST ... zumindest für die nächsten 292471208677,536 Jahre (nicht signierter Beitrag von 81.20.94.37 (Diskussion) 09:18, 11. Apr. 2013 (CEST))
Dass in einem 64-Bit-Speicher der Überlauf nicht stattfindet, ist doch unbestritten. Ob die Software die 64-Bit-Register des Prozessors nutzt oder bei 32-Bit-Variablen bleibt, ist aber alleine Sache der Software. -- Gerd Fahrenhorst (Diskussion) 21:14, 11. Apr. 2013 (CEST)
Das spielt nicht die geringste Rolle bei der grundlegenden Aussage im Artikel - zu behaupten dass das Problem auftreten WIRD weil es fehlerhafte Software geben KANN (bzw. in geringer Anzahl sicher geben wird) ist opportunistische Meinungsmache, Sensations-Schürung und vermutlich noch vieles Weiteres, das mir gerade nicht einfällt. Eine minder gewichtete Nennung dieses potentiellen Umstandes reicht völlig, einige Menschen würden wohl sogar sagen dass es GARNICHT dastehen sollte (ich gehöre nicht dazu) (nicht signierter Beitrag von 95.223.17.23 (Diskussion) 23:20, 11. Apr. 2013 (CEST))

Sehr geehrter Herr IP, machen Sie sich bitte klar dass 64-bit-Prozessoren bis dahin zwar vielleicht im Desktop-Bereich "omnipräsent" sein mögen, der Desktop-Bereich im Vergleich z.B. mit Embedded-Systemen aber nur einen winzigen Anteil am Prozessormarkt hat (nach Stückzahlen gemessen). Tatsächlich werden immer noch mehr 8-bit-CPUs produziert und verkauft als 32er und 64er zusammen. Zwar dürften die wenigsten 8-bitter ein Unix als OS haben, real ist das Problem aber trotzdem. -- 145.228.61.5 12:00, 7. Okt. 2013 (CEST)

Artikel liefert eine falsche Problemanalyse[Quelltext bearbeiten]

Im Artikel heißt es

Am 19. Januar 2038 um 03:14:08 Uhr UTC wird die Anzahl der vergangenen Sekunden die Kapazität einer vorzeichenbehafteten 32-Bit-Ganzzahl (maximal 2.147.483.647) überschreiten.

das ist zutreffend. Die Problemanalyse schreitet dann aber mit einer falschen Deutung fort:

[...] sodass die Zählung bei einer Überschreitung des Wertes 2.147.483.647 (binär 01111111111111111111111111111111) in den negativen Bereich springt

Diese Deutung unterstellt, dass mit Bestimmtheit ein negativer Wert angenommen wird. Das ist aber überhaupt nicht der Fall, weil in der hier (UNIX) maßgeblichen Implementierungssprache C die Inkrementierung einer int-Variable mit dem Wert INT_MAX nur undefined behavior darstellt.

Das Problem mit dieser falschen aber gleichwohl verbreiten Deutung ist, dass von Menschen, die sie wörtlich nehmen, glauben, dass man solche Überläufe nachdem sie geschehen sind erkennen und dann behandeln könnte. Solchen Menschen sind dann bestimmte Nicht-Fehler von Softwaresystemen nicht mehr erklärbar, wie etwa diese zulässige Compileroptimierung. 93.192.156.59 16:37, 11. Jul. 2014 (CEST)

Der Hinweis auf die Unbestimmtheit ist prinzipiell richtig. Es wäre jetzt interessant, wie der Überlauf bei den in der Praxis üblichen Compilern (z.B. GNU, Intel, Microsoft) tatsächlich implementiert ist. Kann jemand dazu Fakten bringen ? -- Gerd Fahrenhorst (Diskussion) 17:17, 12. Jul. 2014 (CEST)
Für die Beantwortung welcher Frage soll das interessant sein? Der Designfehler, dass der verwendete Datentyp die zu speichernden Werte nicht abbilden kann, wird nicht dadurch behoben, dass man weiß, dass auf der einen Maschine die Inkrementierung von INT_MAX INT_MIN liefert während auf einer anderen Implementierung aber eine Prozessor-Ausnahme auftritt. 93.192.148.169 14:40, 14. Jul. 2014 (CEST)
Es stellt sich die Frage, in welcher Form wir das in den Artikel einbauen. Wenn alle verbreiteten Compiler den Übergang INT_MAX -> INT_MIN machen, reicht vielleicht ein kleiner Hinweis dass theoretisch auch andere Reaktionen möglich sind; wenn hingegen die üblichen Compiler mit Exception o.ä. reagieren, wäre ein größerer Umbau des Artikels nötig. Aber vermutlich ist es sowieso komplizierter, weil die Compiler noch durch Aufrufparameter beeinflusst werden können. -- Gerd Fahrenhorst (Diskussion) 20:38, 16. Jul. 2014 (CEST)
Das alles gehört genausowenig in den Artikel, wie es nicht in den Artikel Raub gehört, ob und wenn ja wie ein Räuber mit einer Stichwaffe in das Raubopfer einstechen könnte und/oder ob er danach das Blut und/oder seine Fingerabdrücke abwischt. In den Artikel zu einem Lemma gehört nur das Notwendige hinein und nicht auch noch das, was anlässlich des Lemmas an "Narrativen" zusätzlich denkbar ist. 93.192.144.167 18:42, 19. Jul. 2014 (CEST)
Nur das Notwendigste? Haben wir hier Speicherplatzprobleme? Umfassend, komplett, das ist das Ideal.--Mideal (Diskussion) 15:30, 27. Jan. 2016 (CET)
Jain, guckst Du hier--79.207.149.252 16:09, 20. Nov. 2016 (CET)