Eine relativ einfache Möglichkeit zur Lösung besteht darin, statt der 32 Bit für den Zähler einen 64-Bit-Wert zu benutzen – der würde erst irgendwann in 292 Milliarden Jahren überlaufen, was nun wirklich in etwas weiterer Zukunft liegt. Schaut man sich die aktuellen Entwicklungen zumindest im Endnutzer-Bereich an, werden bis 2038 auch die meisten, wenn nicht alle Systeme auf 64 Bit umgestellt haben. Leider gilt das aber wohl nur für den Endnutzer-Bereich (wenn überhaupt); in den Betrieben werden wohl getreu der “never change a running system”-Doktrin auch 2038 noch etliche Systeme mit einem 32-Bit-Zähler in Betrieb sein, welcher dann überlaufen würde und zu potentiellen Problemen führt. Wie beim Jahr-2000-Problem muss also auch 2038 eine ausgedehnte Suche nach noch laufenden, alten Rechnersystemen stattfinden und es müssen diese durch 64-Bit-Systeme (oder was auch immer 2038 aktuell ist) ersetzt werden. Leider reicht übrigens das Ersetzen der Hardware durch 64-bit-fähige Hardware nicht unbedingt; viele Programme sind derart programmiert, dass sie nur in ihrer 32-Bit-Variante funktionieren – diese müssen dann entsprechend auch umgeschrieben werden, was wohl ähnlich kostspielig wird wie das Jahr-2000-Problem. Immerhin ist das Problem aber bereits heute bekannt und es kann bereits langfristig darauf hingearbeitet werden, die potentiell fehlerhaften Systeme bis zum Jahr 2038 sämtlich zu ersetzen. Ich bin dennoch gespannt (wenn man es so nennen darf), was alles dabei schiefgehen wird und wo überall am 19. Januar und den Folgetagen noch alte, längst vergessene Rechner auftauchen, die seit Jahrzehnten in staubigen Kammern vor sich hin rechneten.

Und zum Abschluss noch das angekündigte Numberphile-Video:

1 / 2 / 3

Kommentare (24)

  1. #1 Volker Birk
    https://blog.fdik.org
    Februar 13, 2013

    “Jeder Computer besitzt intern einen kleinen Zähler, welcher die vergangenen Sekunden seit dem 1.1.1970 zählt und zur Bestimmung des aktuellen Datums und der aktuellen Uhrzeit verwendet wird.”

    Sorry, das ist nicht richtig.

    Zum einen besitzt kein Computer diese Eigenschaft, sondern es handelt sich vielmehr um eine Eigenschaft von älterer Anwendungssoftware für Unix-Systeme und Klone davon wie die mancher GNU-Linux-Systeme, sowie von Software auf manchen eingebetteten Systemen.

    Windows-Software ist nicht betroffen, auch die Anwendungssoftware moderner 64bit-Unix- und GNU/Linux-Systeme nicht, die Anwendungssoftware anderer Betriebssysteme, wie die etwa für OpenVMS, z/OS oder IBM i ebenso nicht.

  2. #2 Spoing
    Februar 13, 2013

    Das sind noch 25 Jahre, so lange wird der nächste Papst niemals durchhalten! Somit wird die Welt ja schon vorher untergegangen sein.

  3. #3 tieftaucher
    Februar 13, 2013

    MillenNium.

    Es heißt “Millennium”.

    Rege ich mich schon seit tause… äähhh mindestens 15 Jahren drüber auf.

    Auch und gerade in einem Science-Blog kann, darf und muss ich das erwarten (dürfen).

    Bitte. Danke.

  4. #4 Marcus Frenkel
    Februar 13, 2013

    @Volker Birk
    Umformuliert, danke.

    @tieftaucher
    Korrigiert, danke.

  5. #5 tieftaucher
    Februar 13, 2013

    @Marcus Ich hab da im Kommentar ‘n Smiley vergessen, sorry. 😉

    Und Du hast das “Millenium” in den Stichworten vergessen! (:

  6. #6 tieftaucher
    Februar 13, 2013

    Ah, nu isses auch in den Stichworten korrigiert!

    Ich mag die Scienceblogs, auch wenn ich manchmal als ambitionierter Laie nur <99% verstehe.

  7. #7 Lukas
    Februar 14, 2013

    @tieftaucher Na 99 % sind doch eine gute Quote!? Bei manchen Artikeln verstehe ich nur Bahnhof und auch davon nur die ersten 3 Gleise…

  8. #8 Stefan W.
    https://demystifikation.wordpress.com
    Februar 14, 2013

    Hätte der Millenniumsbug einen korrekten Namen gehabt, dann wäre der Überlauf von 2000 zu 2001 passiert. 😉

  9. #9 Dr. Webbaer
    Februar 14, 2013

    Das 2000er-Problem entstand wie beschrieben und weil Software, vermutlich sehr oft COBOL-Software, auf Verschleiß gefahren worden ist, zudem schön performant war auf 80×25 und im Netzbetrieb lief und lief…

    Bei der Hardware und dem 2038er Problem dürften die Rechner längst ausgetauscht sein, oder?

    MFG
    Dr. W (der bei der 2000er-Problematik seine Nase in einigen Systemen hate)

  10. #10 Marcus Frenkel
    Februar 14, 2013

    @Webbaer
    Auch 2038 werden wohl noch genügend 32-Bit-Rechner in irgendwelchen Kellern vor sich hin werkeln, von embedded systems gar nicht zu reden. Das ist überhaupt eine interessante Frage: wie viele Rechnerkomponenten sind so überall verbaut, die den Sekundenzähler nutzen? Ich könnte mir vorstellen, dass das eine nicht zu vernachlässigende Anzahl ist.

  11. #11 Wurgl
    Februar 14, 2013

    Ich glaub da muss ein wenig zwischen der Hardware, dem Betriebssystem und der Software getrennt werden.

    Wie ein jeder ja weiß, rennt die Systemzeit fröhlich weiter, wenn der Rechner abgedreht ist — vor ewigen Zeiten, als ein 12 MHz Turbo-XT noch der hammer schlechthin war, da war das nicht so. Da durfte man bei jedem Start die Zeit eingeben. Aber egal, die Zeit läuft also weiter, währen der Rechner abgedreht ist. Und diese Zeit läuft in einem Hardwarezähler der durch eine kleine Batterie oder einem kleinen Akku oder manchmal einfach durch einen Kondensator mit Strom versorgt wird. Dort ist auch ein Zähler drinnen und der läuft auch irgendwann mal über — irgendwann.

    Und dann gibt es das Betriebssystem. Da könnte man jetzt schön streiten und über dieses oder jenes spotten oder es loben. Bringt nix. Ist es ein 64-Bit System, dann besteht wohl kaum Gefahr, ist es ein 32 Bit System, dann könnte es gefährlich werden. Ich sehe aber bei beiden kaum Probleme für typische PCs oder auch für Server, weil da noch 25 Jahre hin sind und das ist eine lange Zeit. Festplatten die ab heute noch 25 Jahre problemlos laufen, würde ich in die Kategorie “Wunder” einordnen, Elkos die nach 25 Jahren immer noch flüssigen und funktionsfähigen Elektrolyt haben ebenso.

    Und dann gibts die Anwendungsprogramme. Da sehe ich schon eher die Gefahr. Da könnte es tatsächlich haarig werden. Nicht weil die Programme so lange im Einsatz sind, sondern weil so manche Sourcen ihre Wurzeln in der “Steinzeit” haben und man damals nun wirklich nicht an so ein Problem gedacht hat, geschweige denn dass Teile des Programms noch in 30+ Jahren eingesetzt werden könnten. Ich selbst hab ein Programm zur Pflege geerbt, welches seine Wurzeln irgendwann vor 1988 sind (Es gibt jedenfalls Änderungskommentare von Juni 1988, also muss die Erstfassung älter sein).

    Problematischer sehe ich das aber bei embedded Systemen, also jenen kleinen Helferleins die in Geräten wie Fernseher, Microwelle, Bügeleisen, Waschmaschine in jedem Haushalt herumwerkeln. Wobei die Dinger im Haushalt eigentlich schnurzpiepegal sind. Problematischer wird es schon in der Steuerung einer Drehbank oder sicherheitstechnischen Anlagen. Ich sehe deshalb eine gewisse Gefahr, weil bei solchen Teilen die Notwendigkeit für 64 Bit einfach nicht besteht und diese Hardware weiterhin auf 32 Bit laufen wird und weil diese Geräte eine deutlich längere Einsatzzeit haben, als irgendein Consumer-Gerät.

    Übrigens hab ich bis vor zwei Jahren noch eine alte Sun IPX als Firewallrechner eingesetzt. Leider musste ich die einmotten, sie schafft es einfach nicht mehr, Mein DSL-Anschluss ist mit momentan 8MB (also echten, nicht die aus der Werbung) einfach zu schnell.

    Ach und noch ein Satz zum Y2K-Problem. Ich hab meine erste Festanstellung irgendwann um 1985/6 gehabt. Damals durfte ich auf so einem “Großrechner” arbeiten. Also ein Teil, das ganz toll 4MB(!) Hauptspeicher hatte, 2 CPUs und im klimatisierten Nebenraum standen ein Haufen Schränke mit Festplatten herum die zusammen stolze 4,x GB Kapazität hatten. An diesem “Großrechner” hingen dann direkt bzw. teilweise über Modem irgendwas um die 300 Terminals. Das war übrigens der drittgrößte rechner in dieser Stadt, die Universität hatte einen baugleichen der etwas dicker ausgestattet war und dann gabs noch die Niederlassung von IBM die einen Rechner mit deutlich mehr Power hatte. Soviel zur Hardware damals.

    Und auf eben dieser Hardware gab es einige große Datenalpträume in denen Informationen zu etwas über einer Million Personen gespeichert waren (es war eine Sozialversicherung). Wenn man sich jetzt die Hardwareausstattung ansieht, dann wird das schon etwas eng, da muss man sparen. Es gab jedenfalls Indizes über diese Daten und unter diesen war ein Aufsteigender der die Anzahl Tage seit einem Zeitpunkt zählte (keine Ahnung mehr ab welchem Stichtag) und ein zweiter absteigender Index, der die Tage bis zum 1.1.2000 zählte. Und dieser zweite absteigende Index war das große Problem über das sich die Abteilungsleiter schon damals Gedanken machten. Wie das ausgegangen ist, weiß ich nicht. Ich war dort nicht sehr lange. Die Versicherung existiert jedenfalls noch 🙂

    Diese Rückblende wollt ich nur mal einwerfen, weil ich denke, dass es heute schwer vorstellbar ist, mit welcher aus heutiger Sicht minimaler Hardware damals gearbeitet wurde. Und weil eben aus diesen Einschränkungen heraus die Probleme erwachsen sind. Das ist heute doch etwas anders.

  12. #12 Dr. Webbaer
    Februar 14, 2013

    Hardware tauscht man schneller aus als Software. Das war der Punkt auf den Ihr Kommentatorenfreund hinauswollte. Zudem müssten die Rechner auch 2036 noch auf ihre eigene Zeitrechnung angewiesen sein, wenn der Schreiber dieser Zeilen folgen konnte.

    Die 2000er-Problematik war auch ein Hype, da wollten IT-nahe Kräfte im kaufmännischen Bereich oft nachweisen, dass sie auch etwas mitkriegen; da wurde dann fleißig projektiert. So richtig cool war es nämlich schon 1980 nicht mehr das Jahr zweistellig zu kodieren.

  13. #13 rolak
    Februar 14, 2013

    Zusätzlich zu der längeren Zählung in der Software braucht es allerdings noch neue interne Hardware (p11f) oder einen Zeitabgleich über diese hinaus. Ist nicht sooo sinnvoll, von etwas falsch Interpretiertem loszuzählen.

  14. #14 Jakob B.
    Februar 14, 2013

    Schöner Artikel! Vorallem da ich weder das Problem kannte noch “Numberphile”. Werde mich jetzt erstmal durch deren Videos wühlen…

    Eine kleine Fragen noch:
    Was hat das ganze denn mit 32Bit- oder 64Bit-Systemen, also dem Adressraum, zu tun? Relevant ist doch nur mit wieviel Bit der Wert zur Verfügung gestellt wird und wie der Counter in der Hardware umgesetzt ist. Die Schnittstelle kann ja auch auf einem 32Bit-System einen 64Bit-Wert liefern, was überlicherweise auch die Programmierer dazu verleitet die folgenden Berechnungen auf 64Bit-Basis durchzuführen.

    Übrigens werden (meiner Erfahrung nach) im erwähnten Embedded-Bereich nicht “1, 4 oder 8 Byte” Werte am häufigsten verwendet sondern 2Byte-Werte. Das liegt einfach daran, dass
    a) Speicherplatz knapp und teuer ist (ich erinner mich an stundenlange Diskussionen mit dem Ziel 20Byte zu sparen)
    und b) viele physikalische Größen mit 2 Byte als Festkommawert mit ausreichender Auflösung dargestellt werden können (Drehzahlen bis 10000U/min mit Auflösung 0.5U/min, Momente mit Auflösung 0.1Nm, etc.)

  15. #15 Marcus Frenkel
    Februar 14, 2013

    Was hat das ganze denn mit 32Bit- oder 64Bit-Systemen, also dem Adressraum, zu tun? Relevant ist doch nur mit wieviel Bit der Wert zur Verfügung gestellt wird und wie der Counter in der Hardware umgesetzt ist. Die Schnittstelle kann ja auch auf einem 32Bit-System einen 64Bit-Wert liefern, was überlicherweise auch die Programmierer dazu verleitet die folgenden Berechnungen auf 64Bit-Basis durchzuführen.

    Es ist richtig, dass auf einem 32-Bit-System auch 64-Bit-Werte verrechnet werden können (zumindest so lange das die darunterliegende Prozessorarchitektur unterstützt). Das eigentlich interessante ist aber, für welche Bitbreite ein Programm kompiliert wurde; der Sekundenzähler wird, wenn ich mich richtig erinnere, über Programmbibliotheken als time_t-Datentyp geliefert, welcher wiederum auf “long” verweist. Die Bitbreite von “long” ist aber zumindest in C/C++ nicht definiert – das können 32 Bit sein, oder auch 64 Bit. Damit ist für Programme primär interessant, wie sie kompiliert wurden.

  16. #16 Wurgl
    Februar 14, 2013

    Marcus: In C ist gar nix an Bitbreiten definiert. long kann auch 17 Bytes breit sein oder 42.

    Dieser Großrechner in meinem langen Kommentar oben hatte übrigens 36 Bit Registerbreite. 36 Bit, weil da passen 6 mal 6-Bit breite “Byte” hinein. Und in 6 Bit passen hervorragend alle Großbuchstaben und Ziffern. Damals sparte man noch wo immer es ging. Da waren sogar Halbbits wichtig.

    Die einzige Definition ist, dass short <= int <=long ist. Können durchaus alle 3 16 Bit breit sein.

  17. #17 Marcus Frenkel
    Februar 14, 2013

    Ja, so war es gemeint. 😉

  18. #18 Uli
    Februar 15, 2013

    Also ich persönlich war heilfroh, als der 1.1.2000 ohne AKW-Explosion oder einen aus Versehen gestarteten thermonuklearen Krieg vorbei war.

    Da muss nur *ein* fehlerhaft programmiertes Untersystem der Meinung sein, uum damit buchstäblich eine katastrophale Kettenreaktion auszulösen.

    Und so wie die AKW-Lobby darum kämpft, die Laufzeiten alter Meiler (und damit der Steuersoftware) immer weiter zu verlängern, kann es durchaus vorkommen, dass einige Programme das Jahr 2038 erleben, was der Software-Entwickler nie bedacht hat und er/sie selbst ist ist dann auch schon lange tot.

    Man hat auch lange Zeit gedacht, 4GB reichen als maximale Dateigröße in einem Dateisystem locker aus.

    Tja, falsch gedacht…

  19. #19 Robert aus WIen
    Februar 15, 2013

    Genaugenommen war der Jahrtausenwechsel erst ein Jahr später, also der Jahreswechsel 2000/2001 – auch wenn in den Medien was anderes behauptet wurde.

  20. #20 Engywuck
    Februar 15, 2013

    ganz witzig waren die Webseiten, die Anno 2000 dann auf einmal Angaben wie “letzte Änderung: 12.3.19100” anzeigten, weil das Jahr seit 1900 genommen und an den String “19” angeheftet wurde (wozu rechnen, geht doch auch so). Die letzte Webseite in diesem Stil die ich gesehen habe hatte damals glaub’ “19105” angezeigt.

    Windows seit NT rechnet intern übrigens in 64bit seit 1.1.1601 und mit 100-Nanosekunden-Schritten. Das reicht für die nächsten paar zehntausend Jahre und man muss nur einen Wert speichern statt Millisekunden extra. Wenn man die denn braucht. 1601 natürlich wegen der gregorianischen Kalenderreform 1582 und weil das das nächste Jahrhundert war (und die Schaltjahrberechnung einfacher wird?)
    Dafür hat sich Win9x aufgehängt(?), wenn es einige Wochen lief: es gab da ‘nen Timer, der die Zeit seit dem Boot angab – und der war halt auf “ach, das wird schon jede Woche mal wer rebooten” ausgelegt 🙂

    Das Dateisystem FAT speichert die Erstellungszeit von Dateien auf 2 Sekunden genau (was ein Problem sein kann, wenn geprüft werden sollte, ob die Datei auf Platte neuer als die auf Diskette/Netzwerk/… ist): für Jahr/Monat/Tag und Stunden/Minuten/Sekunden stehen je zwei Byte zur Verfügung:
    Tag: 5 bit
    Monat: 4 bit
    bleiben für’s Jahr (2*8)-5-4=7 bit, also 128 Jahre ab 1980 (ohne Vorzeichen, vorher kann keine Datei erstellt sein). Reicht. jedenfalls für DOS.
    Stunde: 5 bit
    Minute: 6 bit
    Sekunde: eigentlich ebenfalls 6 bit, aber 5+6+6 sind 17 bit. Also wird das letzte bit der Sekunde auf “0” definiert (“wen interessiert’s schon genauer?”) und schon braucht man nur 5 bit. Passt.
    Dass man mit der Unix-Methode in den 4 Byte auch gleich sekundengenau bis 2038 hätte zählen können hat damals bei Microsoft keinen geschert – Bitoperationen waren halt schneller. Und Sommerzeit… welche Sommerzeit. Oder auch Zeitzonen. Wer Disketten durch die gegend trägt, weiss welche zeitzone das war wo die entstand.

    Mit dem “Erfolg”, dass sich bis heute jeder Admin schonmal darüber geärgert hat und moderne Tools Methoden mitbringen, diese antiken DOS-FAT-Fehler partiell zu eliminieren. Mal als Beispiel: Robocopy hat die Optionen /FFT für FAT-Granularity und /DST um Sommerzeit zu ignorieren.

  21. #21 Dr. Webbaer
    Februar 16, 2013

    @Engywuck
    Interessante Anmerkungen. BTW: Wissen Sie vielleicht, warum DOS bzw. Windows nie [1] mit einem DBS für die Dateiverwaltung kommt, warum das Durchsuchen des Webs zigfach schneller ist als das der Festplatte?

    [1] W7 wurde dbzgl. nicht geprüft

  22. #22 Engywuck
    Februar 18, 2013

    ich vermute Platz- und Zeitgründe.
    W7 (Vista?) bietet aber die Option “Zulassen, dass auf diesem Laufwerk Inhalte zusätzlich zu Dateieigenschaften indiziert werden”, da ist es also drin. Für XP gab’s meines Wissens ebenfalls entsprechende Erweiterungen.

    Und google hat halt *enorme* Kapazitäten. Es hat schon seinen Grund, warum’s grad mal anderthalb wichtige Suchmaschinen für “allgemeine” Inhalte gibt (Spezialsuchmaschinen gibts n paar mehr, aber die indizieren (indexieren?) nicht alles)

  23. #23 Dr. Webbaer
    März 2, 2013

    @Engywuck

    Und google hat halt *enorme* Kapazitäten.

    Entsprechende Kapazitäten hat zumindest vergleichsweise ein handelsüblicher Rechner auch, wenn er bspw. einen Dienst für diese Zwecke ausführt.
    Und es reicht für diese Zwecke auch eine im Vergleich mit Google weit abgespeckte Intelligenz.

  24. #24 Compuholic
    März 15, 2013

    @Webbaer:

    Windows bietet schon lange eine solche Funktion. Windows 2000 wurde standardmäßig mit dem Indexdienst ausgeliefert. Erhältlich war er aber auch schon für NT 4.0. Der Indexdienst wurde in späteren Versionen dann durch Windows Search ersetzt. Der Index lässt sich unter anderem jetzt auch übers Netzwerk nutzen und außerdem lassen sich Inhalte des Exchange Servers indizieren.

    Entsprechende Kapazitäten hat zumindest vergleichsweise ein handelsüblicher Rechner auch, wenn er bspw. einen Dienst für diese Zwecke ausführt.

    Abhängig davon, was alles indiziert wird, kann der Index aber eine ganze Menge Speicher belegen. Und der Aufbau des Index ist auch nicht ganz ohne.

    Habe grade mal für W7 nachgeschaut was alles indiziert wird. Standardmäßig werden nur die persönlichen Ordner, Bookmarks, Synchronisierte Dateien und das Startmenü indiziert. Was genau indiziert wird, hängt vom Dateityp ab. Office Dokumente und PDFs werden z.B. im Volltext indiziert, die meisten Dinge aber nur nach Dateieigenschaften.