Diskussion:Jahr-2038-Problem/Archiv

aus Wikipedia, der freien Enzyklopädie

Belege

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)

Dann will ich für "Fachkreise" aber auch Belege haben... --Rbrausse 09:44, 14. Feb 2006 (CET)

Eine Umfrage in einer grossen Entwicklungsabteilung für Telekommunikation sowie einer fuer Transaktionen im Einzelhandel ergab: "nicht dringlich". Allerdings gilt die Handhabung von Zeitstempeln generell als ueberarbeitungswuerdig - man nimmt halt, was das System anbietet. GuidoD 14:00, 14. Feb 2006 (CET)

Dann freue ich mich auf das SAP-Jahr-10000-Problem ;) --Rbrausse 16:08, 16. Feb 2006 (CET)

Zahl korrekt?

Rein aus Interesse: stimmt es, dass das Datum auf den 13. Dezember 1901 springt? Ich würde davon ausgehen, dass auf den 01.01.1970 gesprungen wird. Das 32. Bit wird gesetzt und alle anderen springen auf 0. Da dann die Zeit quasi Rückwärts laufen müsste (ist ja negativ) dürfte so ziemlich jedes System dadurch abstürzen.

Oder habe ich da einen Denkfehler? --Daniel-Edertal 14:56, 06. Jan 2009 (CET)

Das 32.te bit wird als Vorzeichen gezählt - bei Zeitbasis 1970 wird der Abstand plus-69-Jahre auf minus-69-Jahre springen. GuidoD 15:20, 6. Jan. 2009 (CET)
Das ergibt aber durchaus Sinn. Immerhin ist ja auch ein Programm erforderlich, dass dann daraus ein Lesbares Datum macht. Je nachdem was das für Befehle verwendet, kann es sein das das Vorzeichenbit vernachlässigt wird. Oder es wird der Variablentyp UNSIGNED LONG verwendet,(Was in Programiersprachen mit Typumwandlung möglich ist) der dazu führt, dass es erst 2106 auf 1970 springt [Was dann ein großes Problem für viele DOS Benutzer wird :-)] -- Gruß Pinnipedia 23:50, 3. Sep. 2010 (CEST)
Das ist Unsinn, siehe Einleitungssatz:
"Dieses Problem ist auf EDV-Systeme beschränkt, die den POSIX-Zeitstandard benutzen und time_t als vorzeichenbehaftete 32-Bit-Binärzahl definieren."
Jegliche Diskussion wann das Problem auftritt oder dass ggf. irgend ein Programmierer gepfuscht hat ist unherblich, da der Artikel klar definiert dass er bei time_t-Systemen mit 32-Bit signed auftritt. Genausogut könnte man sagen, dass DATETIME nicht funktioniert, weil es könnte ja ein Programmierer den Fehler gemacht haben und 2000-02-30 00:00:00 als gültigen Wert betrachten --suit Datei:Rebell at 13x13.jpg 03:08, 4. Sep. 2010 (CEST)

Auf POSIX beschränkt?

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 ([1]) --Oefe 21:58, 11. Jan. 2010 (CET)

MSB oder msb?

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)

13.12.1901

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

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

Ist das 2038 Jahres Problem wirklich ein Problem?

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

Ich sehe daen Artikel als ziemliche Glaskugelei, da er nur ein hyptotetisches Problem beschreibt, auf dessen Auftreten wir noch knapp 30 Jahre warten müssen...-- · peter schmelzle · d · @ · 18:58, 20. Okt. 2010 (CEST)

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)

Quellen quälen

Bitte Literatur oder and. Quellen angeben. danke --löschfix 14:20, 5. Jan. 2010 (CET)

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)

2010

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)

"... Jahr-2000-Problem, welches sich im Wesentlichen beim Datumsstempel von Dateien äußerte, ..."

Ich halte diese Aussage im Artikel für falsch. Sie wurde hier unbequellt eingefügt. Ich behaupte sogar, dass "Datumsstempel von Dateien", also der im Filesystem gespeicherte Zeitstempel des Anlegens, letzten Zugriffs o.ä. dieser Datei, nicht nur kein Wesentliches, sondern wenn überhaupt, dann nur ein sehr geringes Problem war, ggf. auf wenige Betriebssystem beschränkt, die nicht gängig sind. Die Aussage findet sich auch im Artikel zu Y2K nicht, wenn ich mich nicht verguckt habe. Dort steht aber zurecht, dass das Haupt-Y2K-Problem im Speichern von Timestamps lag (im Speicher oder in Dateien). Ich habe 98/99 Hunderte von Y2K-Problemen in verschiedenen Systemen unter verschiedenen Betriebssystemen behoben und da war kein einziges, das einen Datumsstempel einer Datei betraf.

Wenn da keine Quelle nachgereicht wird, werde ich die Aussage rausnehmen. --AchimP 14:15, 24. Jan. 2011 (CET)

Das Jahr-2000 Problem hat sich bei UNIX genau an zwei Stellen geäußert: sccs hatte Zweistellige ASCII Jahreszahlen im Dateiformat und troff Makros haben 1900 + Jahresdelta nicht sauber als integer ADD implementiert, sondern als Strinzusammenschluß (z.B. "19" "90"). --Schily 15:15, 24. Jan. 2011 (CET)
Dann sollte der Satz mit "im Unix-Betriebssystem" ergänzt werden, da sich die Aussage dann (im Gegensatz zum Y2038-Problem) insbesondere nicht auf Anwendungsprogramme unter Unix bezieht. Da sich der nachfolgende Halbsatz aber quasi nur auf Fehler in Anwendungsprogrammen bezieht, frage ich mich, was da gegenübergestellt werden soll. --AchimP 16:30, 24. Jan. 2011 (CET)
Ich bin mir jetzt nicht klar darüber ob Du das richtig verstanden hast.... sccs ist ein Anwendungsprogramm, troff Makros beeinflussen Anwendungsprogramme wie troff oder man(1). Es hab aber kein Y2000 Problem unter UNIX das Relevanz für Dateien hatte. Da passiert erst etwas nach 2038, bzw. schon jetzt wenn eine Datei aus der Zeit vor 1970 über NFS exportiert wird. --Schily 18:21, 24. Jan. 2011 (CET)
Wie definierst Du denn "Anwendungsprogramm"? Ich hatte aufgrund Deiner Aussage gedacht, Du zähltest sccs als "Systemprogramm" mit zu Unix, so wie "man" ein Systemprogramm ist (== üblicherweise mit Unix ausgeliefert, also zum "Unix-Betriebssystem gehörend"). Selbst wenn Du "sccs" und "man" als Anwendungsprogramme bezeichnest, so ist doch auch jedes Programm, das eine Firma X für eine Firma Y schreibt, ein Anwendungsprogramm. Und ich vermute, Du willst nicht wirklich behaupten, in den hunderttausenden solcher unter Unix geschriebenen Anwendungen seien nur in zweien Y2K-Fehler gewesen?
Können wie also festhalten, dass vielleicht "im Unix-Betriebssystem und seinen üblicherweise mitausgelieferten (Anwendungs-)Programmen" hauptsächlich "Datumsstempel von Dateien" ein Problem waren, aber durchaus nicht unter allen übrigen Unix-(Anwendungs-)Programmen? --AchimP 18:43, 24. Jan. 2011 (CET)
Anwendungsprogramme die nicht mit bei UNIX standardmäßig ausgeliefert werden kann man schlecht mitzählen und vor Allem nicht für dieses Problem bewerten. Dataumsstempel von Dateien waren für das Jahr 2000 Problem nicht relevant, sie werden es für das Jahr 2038 Problem in 27 Jahren werden. --Schily 22:31, 24. Jan. 2011 (CET)
Dass Datumsstempel von Dateien für Y2K nicht relevant waren, ist doch meine Rede. Der Satz im Artikel behauptet aber das Gegenteil. Du willst ihn trotzdem so lassen? --AchimP 00:33, 25. Jan. 2011 (CET)
Die Behauptung im Artikel ist natürlich Unsinn, auch der darauf folgende Halbsatz.... Banken und Versicherungen verwenden seit Ende der 1990er Jahre 64-Bit Systeme. Wenn die Banken daher ein Problem im Jahr 2038 haben, dann durch unsaubere Eigenprogrammierung. --Schily 10:22, 25. Jan. 2011 (CET)
Oh, dann sind wir uns ja einig. --AchimP 13:01, 25. Jan. 2011 (CET)

290 Milliarden Jahre

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)
*hust*, klar, unser Sonnensystem existiert in 290 Milliarden Jahren ja noch … ;-) 84.185.100.165 20:16, 22. Mai 2006 (CEST)
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)
Wer auch immer *diesen* Satz geschrieben hat, Gratulation! Der ist wirklich gut. --89.61.93.44 09:21, 11. Feb. 2007 (CET)
Aber er bleibt Spekulation.--löschfix 14:17, 5. Jan. 2010 (CET)

Zur Zahl

Ich finde diese Information gerade für den Laien evtl. sinnvoll (bin selber keiner :P) da diese veranschaulicht wie groß der unterschied zwischen 32 und 64 Bit ist :-)--80.134.233.51 23:18, 20. Mär 2006 (CET)

Dem stimme ich zu: Die Zahl verdeutlicht sehr schön den Unterschied zwischen 32 und 64 Bit. Allerdings kann der rein akademische Begriff „Jahr-292.277.026.596-Problem“ wohl entfernt werden. --TM 18:50, 21. Mär 2006 (CET)

Ist sicher kein akademischer Begriff... -- Amtiss, SNAFU ? 23:28, 21. Mär 2006 (CET)
„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)
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)
TM, gehst du zum Lachen in den Keller oder hast du dir das grundsätzlich abgewöhnt?--Goodmorningworld 03:33, 11. Nov. 2008 (CET)

Hallo zusammen,
der Satz sprach von einer "technischen Zeitabbildung" von ca. 290 Milliarden Jahre. Da das ja tatsächlich stimmt, handelt es sich dabei keinesfalls um Spekulation. Er besagt im Wesentlichen, daß das Problem für "alle irdische Zeit" gelöst ist. Daß ein philosophisch-theoretischer Rest für den Ausdruck "alle Zeit" besteht, wurde hier bereits ausreichend dargelegt, und hier darf man in diesem Sinne auch jederzeit spekulieren, im Artikel hat das aber nur in sofern etwas zu suchen, wenn damit ein Zusammenhang erklärt werden soll. Dann, entsprechend kenntlich gemacht, aber natürlich auch das. Technisch muß er aber in jedem Falle in irgendeiner Weise begrenzt sein (siehe auch Thema Googol). Ich konnte einen Satz mit den "technischen 290 Mrd. Jahren" aber im Artikel nirgends finden. Hab ich ihn nur übersehen?
Viele Grüße!
Friedrich Hoffmann (Diskussion) 09:08, 20. Dez. 2012 (CET)

Bereits heute ein relevantes Problem

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)

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)

80. Geburtstag

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

Neue Unixe haben das Problem nicht

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)

Code, um Aussagen des letzten Abschnitts zu prüfen

// y2038-test.c
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

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

Abgerufen von „https://de.wikiup.org/index.php?title=Diskussion:Jahr-2038-Problem/Archiv&oldid=207888602“