Diskussion:Jahr-2038-Problem/Archiv

message: Das absehbare Jahr-292.471.208.678-Problem wird allerdings in Fachkreisen nicht als dringlich angesehen. - Klasse. Das gefällt mir ;) --84.144.98.186 09:59, 19. Dez 2005 (CET)
thread_title:  Belege 

message: Die Einleitung behauptet: Dieses Problem ist auf EDV-Systeme beschränkt, die den POSIX-Zeitstandard benutzen und time_t als vorzeichenbehaftete 32-Bit-Binärzahl definieren.
Das stimmt so nicht, time_t ist auch Bestandteil des ANSI-C-Standards, und wurde auch in C-Compilern auf vielen nicht-POSIX-Systemen als 32-Bit Integer implementiert. Zum Beispiel in älteren Versionen von Microsoft Visual C++. Erst seit Visual Studio 2005 ist time_t 64 Bit () --Oefe 21:58, 11. Jan. 2010 (CET)
thread_title:  Auf POSIX beschränkt? 

message: Ich bin mit diesem Thema noch nicht so vertraut, aber mir ist eben folgendes aufgefallen.
Im Artikel steht: "Das signifikanteste Bit (MSB) wird laut Konvention dazu verwendet, positive und negative Zahlen zu unterscheiden[...]". Mal gut soweit; im MSB Artikel wird dann folgendes beschrieben: "Es ist allgemein üblich, Bit mit "b" und Byte mit "B" abzukürzen. Analog dazu bezeichnet msb (kleingeschrieben) das "most significant bit", während man mit MSB in der Regel das "most significant byte" meint.".
Sollte dann nicht eben genau der Verlinkungstext msb anstatt MSB lauten um für keine Verwirrung zu sorgen?
Ist nur etwas kleines und ich weiss auch nicht ob es korrekt ist. Wenn ja, bitte ändern ;) --Bugybunny 15:27, 15. Aug. 2010 (CEST)
thread_title:  MSB oder msb? 

message: Ich habe eben in PHP ausprobiert was das größte und das kleinste darstellbare Datum ist. Das größe stimmt tatsächlich, aber beim kleinsten ist bei mir nach 13.12.1901 20:55:13 MEZ Schluss. Liegt das an PHP, oder habt Ihr euch verrechnet?? (nicht signierter Beitrag von 87.167.72.63 (Diskussion | Beiträge) 17:59, 16. Nov. 2008 (CET)
replies: text: Rechnest du Schaltsekunden, Schaltstunden, Schalttage, Nicht-Schaltjahre korrekt mit? (nicht signierter Beitrag von 87.158.98.227 (Diskussion | Beiträge) 22:24, 1. Mär. 2009 (CET)
thread_title:  13.12.1901 

message: Ich weiss ja das man in der Grossrechner Welt durchaus Programme haben kann die 30 Jahre alt werden aber Programme die von 1970 bis 2038 ohne Anpassung laufen, kann ich mir ehrlich gesagt nicht vorstellen. Das wären Programme die 68 Jahre ohne Softwareveränderung noch laufen würden. Wer soll sowas denn glauben? (Der vorstehende, nicht signierte Beitrag stammt von 85.178.40.249 (Diskussion • Beiträge) 02:22, 16. Jun. 2007) 
:Heute wäre das jedenfalls noch ein Problem. Genau wie die Umstellung auf IPv6 geht auch die Umstellung auf 64-Programme sehr langsam vonstatten. Dass es dennoch unwahrscheinlich ist, dass es 2038 Probleme gibt, macht den Artikel nicht überflüssig. -- Amtiss, SNAFU ? 18:37, 16. Jun. 2007 (CEST)
replies: text: Nein, die Programme laufen nicht seit 1970. Der 01.01.1970 wird als Startpunkt für die Zeitstempel benutzt. Die Programme wurden also durchaus angepasst, allerdings haben sie immer wieder den gleichen Datentyp benutzt. --Shepard 22:41, 15. Sep. 2007 (CEST)

text: Ab wann hattest Du denn Y2K als nicht-hypothetisches Problem angesehen? Ab dem 1.1.2000 0h00? Da wäre es leider zu spät gewesen. Im übrigen kannst Du das Problem auf den meisten Systemen jederzeit ganz real verifizieren, indem Du die Systemzeit entsprechend vorstellst. --AchimP 21:10, 20. Okt. 2010 (CEST)
thread_title:  Ist das 2038 Jahres Problem wirklich ein Problem? 

message: Bitte Literatur oder and. Quellen angeben. danke --löschfix 14:20, 5. Jan. 2010 (CET)
replies: text: Was ist hier los? Die Quelle ist der gesunde Menschenverstand und/oder ein Taschenrechner, evtl. könnte man auch auf den entsprechenden Sourcecode verweisen. Generell haben die Diskussionen über diesen Artikel ein Niveau erreicht, was sich unter „intellektuelle Masturbation“ zusammenfassen lässt. --87.157.208.106 17:54, 15. Dez. 2010 (CET)
thread_title:  Quellen quälen 

message: Dieser Artkel ist hoffentlich kein Kindergarten. Das Jahr 2038 Problem ist UNIX/POSIX-spezifisch, daher ist dieser Artikel POSIX Spezifisch. Das Jahr 2010 Problem ist aber definitiv ohne jeden Bezug zu POSIX. Wer daran interessiet ist, findet den Link auf der Sammelseite zu Softwarefehlern. --Schily 13:48, 24. Jan. 2011 (CET)
thread_title:  2010 

message: Technisch betrachtet behebt die 64-Bit-Umstellung das Zeitstempelproblem nicht endgültig, sondern das Jahr-2038-Problem wird um etwa 290 Milliarden Jahre in die Zukunft verschoben ("Jahr-292.277.026.596-Problem").
Dieses Jahr wird die Menschheit allerdings wohl nicht erreichen, da die Lebensbedingungen auf der Erde sich bis dahin durch ökologischen Raubbau etc. so negativ beeinflusst haben werden, dass dies keine Rolle mehr spielen dürfte. -- aus Artikel ausgelagert
:: Und sollten wir trotzdem so lange weiter bestehen, bohren wir den Zähler halt auf 128 Bit auf. -- 79.210.54.35 17:50, 1. Jan. 2010 (CET)
replies: text: *hust*, klar, unser Sonnensystem existiert in 290 Milliarden Jahren ja noch … ;-) 84.185.100.165 20:16, 22. Mai 2006 (CEST)

text: Gibt sicher weniger spekulative Gründen, warum das Problem irrelevant ist. Außerdem könnte die Menschheit durch technologische Revolutionen doch in der Lage sein, andere Planeten zu besiedeln. Letztendlich ist und bleibt der Satz eine Anekdote, die nicht dazu genutzt werden sollte, den Artikel weiter aufzublähen. -- Amtiss, SNAFU ? 18:54, 21. Feb 2006 (CET)
replies: text: Wer auch immer *diesen* Satz geschrieben hat, Gratulation! Der ist wirklich gut. --89.61.93.44 09:21, 11. Feb. 2007 (CET)
replies: text: Aber er bleibt Spekulation.--löschfix 14:17, 5. Jan. 2010 (CET)

text: Ist sicher kein akademischer Begriff... -- Amtiss, SNAFU ? 23:28, 21. Mär 2006 (CET)
replies: text:  „Als akademische Frage [wird] ein Problem bezeichnet, dessen Lösung nur wenig oder keine praktische Relevanz für die ursprüngliche, eigentliche Fragestellung besitzt.“ Ich würde den Satz „Das Jahr-292.277.026.596-Problem wird allerdings nicht als dringlich angesehen.“ entfernen, zumal ein Problem auch gar nicht dringlich sein kann – eilen kann nur eine Lösung. --TM 10:44, 22. Mär 2006 (CET)
replies: text:  Darfst deinen Vorschlag umsetzen; ein akademischer Begriff ist für mich nicht dasselbe wie eine akademische Frage. -- Amtiss, SNAFU ? 21:52, 23. Mär 2006 (CET)
replies: text: TM, gehst du zum Lachen in den Keller oder hast du dir das grundsätzlich abgewöhnt?--Goodmorningworld 03:33, 11. Nov. 2008 (CET)
thread_title:  290 Milliarden Jahre 

message: Bereits heute kann es zu Jahr-2038-Problemen kommen, wenn ein Datum aus der Zukunft abgespeichert und verarbeitet werden muss.
So gibt es z.B. langlaufende 30-jährige (Staats-)Anleihen, diese sind dann z.B. 2042 fällig, wenn sie jetzt ausgegeben werden.
In entsprechenden IT-Systemen wurde das unter anderem dadurch gelöst, dass die meisten Timestamps auf Fliesskommazahlen umgestellt wurden.
Dadurch müssen nicht alle Systeme gleich von 32 auf 64 Bit umgestellt werden, was ein viel grösserer Aufwand wäre, denn 8-Byte-Fliesskommazahlen (Double) sind auf allen Systemen gleich.
Bei Script-Sprachen muss dann sogar kaum was am Programm-Code geändert werden, weil hier der Datentyp automatisch erkannt wird.
--Oliver Kurmis (Diskussion) 17:12, 21. Aug. 2012 (CEST)
replies: text: Das sind Anwendungsprogramme. Da kann man Datenformate frei festlegen; Zeiten meinetwegen als 1024-bit-Felder. Wenn aber das Betriebssystem beschließen sollte, im Jahr 2038 Feierabend zu machen, haben Anwendungsprogramme automatisch verloren. Und ja, Workarounds existieren - bis möglicherweise 2038. Andererseits hat es im Jahr 2000 A.D. ja auch größtenteils geklappt, nur Compuserve hat mir dann Mails von 1901 geschickt.
--BlueDino (Diskussion) 00:13, 21. Dez. 2012 (CET)
thread_title:  Bereits heute ein relevantes Problem 

message: Mit Schmunzeln verfolge ich diese Diskussionen.
Sollte ich meinen 80. Geburtstag erleben, freue ich mich schon drauf, dann zu sehen, was da tatsächlich passiert.
Übrigens bemerkenswert, wer an diesem Tag alles Geburtstag hat:
- E.A. Poe
- Robert E. Lee
- Janis Joplin
- Markus Wolf (nicht signierter Beitrag von 84.168.209.101 (Diskussion) 17:01, 27. Feb. 2014 (CET)
thread_title:  80. Geburtstag 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Neue Unixe haben das Problem nicht 

message: // y2038-test.c
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include 
int main() {
        char* fmt = "int i: %d 0x%x\n";
        int i = INT_MAX;
        printf("int i: %d 0x%x\n", i, i); 
        i++;
        printf("int i: %d 0x%x\n", i, i);
        printf("\n");
        fmt = sizeof(time_t)==sizeof(long int)
                ? "time_t f: %ld 0x%lx\n"
                : "time_t f: %d 0x%x\n";
        time_t t = INT_MAX;
        printf(fmt, t, t); 
        printf("ctime(f): %s\n", ctime(&t));
        t++;
        printf(fmt, t, t);
        printf("ctime(f): %s\n", ctime(&t));
        t = i;
        printf("ctime(i): %s\n", ctime(&t));
        return 0;
}
# Kompilation und Beispielausgaben auf einem 64-bit Unixoid
$ uname -srvmpio
Linux 4.19.0-041900-generic #201810221809 SMP Mon Oct 22 22:11:45 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ gcc -v |& grep "^Target\|^gcc version"
Target: x86_64-linux-gnu
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04) 
$ gcc -m32 -o y2038-test-32 y2038-test.c
$ gcc -m64 -o y2038-test-64 y2038-test.c  # -m64 ist Standard auf x86_64, hier zur Verdeutlichung angegeben
$ ./y2038-test-32
int i: 2147483647 0x7fffffff
int i: -2147483648 0x80000000
time_t f: 2147483647 0x7fffffff
ctime(f): Tue Jan 19 04:14:07 2038
time_t f: -2147483648 0x80000000
ctime(f): Fri Dec 13 21:45:52 1901
ctime(i): Fri Dec 13 21:45:52 1901
$ ./y2038-test-64
int i: 2147483647 0x7fffffff
int i: -2147483648 0x80000000
time_t f: 2147483647 0x7fffffff
ctime(f): Tue Jan 19 04:14:07 2038
time_t f: 2147483648 0x80000000
ctime(f): Tue Jan 19 04:14:08 2038
ctime(i): Fri Dec 13 21:45:52 1901
Die Aussage, dass  könne, ist also nur bedingt richtig. 32-bit Kompilate stellen das Problem auch auf einem x86-64 Prozessor zur Schau.
Außerdem kann, wie die Ausgabe ctime(i) zeigt, ein Überlauf auch in 64-bit Kompilaten stattfinden, wenn der Code nicht sauber programmiert wurde und nicht konsequent der Datentyp time_t für Zeitstempel benutzt wurde.  Denkbar ist z.B. das I/O mittels scanf() in eine int-Variable erfolgt und ctime() sowie ähnliche Funktionen mittels impliziter Typumwandlung benutzt werden.  Die Zeitfunktionen lassen sich nämlich durchaus verwenden, ohne das die Eingabenvariablen vom Typ time_t sind.  Auch wenn heute evtl. niemand solchen Code schreiben würde (!?), ist es nicht unwahrscheinlich, dass Legacy-Code genau das macht, anstatt Variablen durchgängig mit time_t zu deklarieren. --84.135.124.75 05:21, 18. Nov. 2018 (CET)
thread_title:  Code, um Aussagen des letzten Abschnitts zu prüfen 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: Nur das Notwendigste? Haben wir hier Speicherplatzprobleme? Umfassend, komplett, das ist das Ideal.--Mideal (Diskussion) 15:30, 27. Jan. 2016 (CET)
replies: text: Jain, guckst Du hier--79.207.149.252 16:09, 20. Nov. 2016 (CET)
thread_title:  Artikel liefert eine falsche Problemanalyse 

message: Wieso nutzt man für einen Timestamp, welcher qua. Definition nicht negativ wird, da er immer nur Inkrementiert wird ein Vorzeichen behafteten Datentyp? --94.134.251.62 01:43, 21. Jan. 2021 (CET)
thread_title:  Vorzeichenbehafteter Wert