Diskussion:Jahr-2038-Problem

Vorlage:Archiv Tabelle

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

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

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

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

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

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

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

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

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

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

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

// y2038-test.c
#include<limits.h>
#include<stdio.h>
#include<stdlib.h>
#include<time.h>
intmain(){
char*fmt="int i: %d 0x%x\n";
inti=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(longint)
?"time_t f: %ld 0x%lx\n"
:"time_t f: %d 0x%x\n";
time_tt=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));
return0;
}

# Kompilation und Beispielausgaben auf einem 64-bit Unixoid
$uname-srvmpio
Linux4.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
gccversion7.3.0(Ubuntu7.3.0-27ubuntu1~18.04)
$gcc-m32-oy2038-test-32y2038-test.c
$gcc-m64-oy2038-test-64y2038-test.c# -m64 ist Standard auf x86_64, hier zur Verdeutlichung angegeben

$./y2038-test-32
inti:21474836470x7fffffff
inti:-21474836480x80000000
time_tf:21474836470x7fffffff
ctime(f):TueJan1904:14:072038
time_tf:-21474836480x80000000
ctime(f):FriDec1321:45:521901
ctime(i):FriDec1321:45:521901

$./y2038-test-64
inti:21474836470x7fffffff
inti:-21474836480x80000000
time_tf:21474836470x7fffffff
ctime(f):TueJan1904:14:072038
time_tf:21474836480x80000000
ctime(f):TueJan1904:14:082038
ctime(i):FriDec1321:45:521901

Die Aussage, dass „auf einem x86-64 Prozessor [..] KEIN ÜBERLAUF STATTFINDEN" 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) Beantworten

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

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

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

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

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

Nur das Notwendigste? Haben wir hier Speicherplatzprobleme? Umfassend, komplett, das ist das Ideal.--Mideal (Diskussion) 15:30, 27. Jan. 2016 (CET) Beantworten

Jain, guckst Du hier--79.207.149.252 16:09, 20. Nov. 2016 (CET) Beantworten

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

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

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:44, 21. Jan. 2021 (CET) Beantworten