Vom Millennium-Bug oder dem Jahr-2000-Problem haben sicherlich viele schon einmal gehört; das Jahr-2038-Problem dagegen ist aber vermutlich nicht ganz so verbreitet. Beide Probleme haben (bzw. hatten) etwas mit der Zeitdarstellung im Computer zu tun, wobei allerdings jeweils ein anderer Mechanismus Ursache des Problems ist/war. Schauen wir uns daher einmal beide Probleme im Detail an. Die Inspiration kam übrigens durch ein Numberphile-Video auf Youtube (ich kann den Kanal sehr empfehlen), welches am Ende des Artikels eingebettet ist.

Das Jahr-2000-Problem

Fangen wir mit dem Jahr-2000-Problem an, insbesondere auch, da das glücklicherweise mittlerweile erledigt ist. Der Kern des Jahr-2000-Problems – ich möchte weniger von einem Bug reden, da das Problem zusammen mit den Bedingungen für das Auftreten lange im Voraus bekannt war – war die Darstellung von Jahreszahlen in den früheren Jahren der Softwareentwicklung.

Prinzipiell lassen sich Zahlen im Computer auf 2 Arten darstellen: in ihrer binären Form (die 1310 entspricht etwa der 11012 – wir erinnern uns), oder in der Darstellung der einzelnen Positionen der Zahl durch ihre Ziffern (im Falle der 13 also “1” und “3”). Der Vorteil der Binärdarstellung ist, dass Zahlen unabhängig von ihrer Größe zur Speicherung eine feste, geringe Menge an Speicherplatz – in der Regel 1, 4 oder 8 Byte (8, 32 bzw. 64 Bit) – benötigen. Der Nachteil dagegen ist, dass in Binärform gespeicherte Zahlen nicht einfach so auf dem Bildschirm dargestellt werden können. Zur Darstellung von Zeichen müssen diese im ASCII-Format (wir erinnern uns) – oder einem erweiterten Format – abgelegt werden; hierbei wird jedes Zeichen (also jeder Buchstabe, jede Zahl, jedes Satzzeichen usw.) durch eine 1-Byte-Zahl (oder bei erweiterten Formaten entsprechend größere Zahlen) codiert. Der Buchstabe ‘A’ entspricht hierbei etwa der Zahl 65, die Ziffer ‘1’ der 49 und so weiter. Zur Darstellung der 13 werden also 2 Byte benötigt – eines für jede Ziffer.

Das eigentliche Problem dieser Art der Darstellung ist, dass oft zur Darstellung von Jahreszahlen lediglich die letzten beiden Ziffern, also etwa ’85’, verwendet wurden (Speicher war teuer damals, und man musste so viel davon sparen, wie möglich). Solange klar war, dass die ausgelassenen Ziffern für ’19’ (also das 20. Jahrhundert) standen, war alles in Ordnung. Zum Jahrtausendwechsel ergab sich aber ein Problem: die letzten beiden Ziffern der gespeicherten Jahreszahlen würden zurück auf ’00’ wechseln, ohne dass eine Information über das neue Jahrtausend (’20’ am Anfang der Zahl) in der gespeicherten Zahl enthalten wäre.

Die Folgen wären etwa gewesen, dass Berechnungen* falsch durchgeführt worden wären (00 – 85 ist ja doch etwas anderes als 2000 – 1985) oder dass Datensätze eine falsche Sortierung bekommen hätten (z.B. die ’00’er-Datensätze nach oben und die ’85’er-Sätze nach hinten bei einer Sortierung nach kleinstem Jahr); eine weitere Folge wäre gewesen, dass Datumsangaben das falsche Jahrtausend enthalten hätten, etwa ‘1900’ statt ‘2000’, da die ’19’ fest verdrahtet war und nur die letzten beiden Ziffern dynamisch gespeichert wurden.

*Mit Zahlen in der Ziffernschreibweise lässt sich natürlich nicht gut rechnen; hier ist eine vorherige Rückwandlung in eine binäre Darstellung nötig. Das Problem bleibt dabei aber natürlich bestehen, da ja keine Information über das Jahrtausend mit abgespeichert wurde.

Nun kann man sich natürlich fragen, wie es überhaupt zu diesem Problem kommen konnte – immerhin war lang genug bekannt, dass das Jahrtausend irgendwann endet und neue Ziffern für die Jahresdarstellung nötig wurden. Zudem war Speicherplatz gegen Ende des Jahrtausend auch nicht mehr so teuer, dass derart knausrig mit ihm umgegangen hätte werden müssen, wobei das nur bedingt stimmt – sogenannte eingebettete Systeme (englisch ’embedded systems’), also sehr spezialisierte, kleine Rechner, verfügen auch heutzutage über sehr wenig Speicher, dessen Nutzung genau geplant werden möchte. Viel wichtiger ist aber, dass zur Jahrtausendwende noch unglaublich viele unglaublich alte Computersysteme liefen; bei der Erstellung dieser Systeme hatte niemand damit gerechnet, dass sie so lange laufen würden, oder dass immer neue Systeme auf Basis der bestehenden entwickelt werden würden. Das Problem war also schlicht hausgemacht: das Problem wurde anfangs nicht berücksichtigt, weil niemand daran glaubte, dass es zum Problem werden würde. Da aber viele den Ausspruch “never change a running system” sehr wörtlich nehmen, gab war zur Jahrtausendwende (und auch heute noch!) viel alte Software im Einsatz, die mit der Jahrtausendwende nicht umgehen konnte.

Die Lösung des Problems bestand am Ende daraus, alle Systeme zu identifizieren, die ein derartiges Problem zur Jahrtausendwende hätten haben können, und sie entsprechend anzupassen, etwa durch Anpassung der Software oder den Ersatz durch neue Programme. Das Anpassend oder Ersetzen der Software war natürlich schon aufwändig und teuer genug; als ebenso großes Problem hat sich aber auch der Umstand erwiesen, dass viele Betreiber von Computersystemen überhaupt nicht mehr im Detail wussten, wo sie überall Geräte im Einsatz hatten, die Jahreszahlen im entsprechenden Format speicherten. Zur Jahrtausendwende wurden zwar die meisten dieser Systeme identifiziert und korrigiert, einige wenige (glücklicherweise minder schwere) Fälle von meist falschen Datumsdarstellungen traten aber trotzdem auf. Mit geschätzten Kosten zwischen 300 und 600 Milliarden Dollar1 zur Behebung bzw. Vermeidung war das Jahr-2000-Problem definitiv keine Lappalie, führte aber glücklicherweise auch nicht zu den den prophezeiten Katastrophenszenarien.

Jahr-2038-Problem

Im Jahr 2038 – konkret am 19. Januar 2038, 03:14:08 Uhr – wird uns ein neues, wieder mit einer Datumsdarstellung verbundenes Problem ereilen. Diesmal wird das Problem zwar weniger “hausgemacht” als vielmehr technisch bedingt sein, die Konsequenzen könnten aber um einiges dramatischer als beim Jahr-2000-Problem werden, wenn sich nicht entsprechend darauf vorbereitet wird. Aber im Detail.

Jeder Computer besitzt Viele Betriebssysteme, insbesondere die Unix-basierten, besitzen 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. Dieser Zähler ist normalerweise als vorzeichenbehaftete 32-Bit-Zahl implementiert (wir erinnern uns), das heißt, dass 31 Bit zur Codierung der Zahl zur Verfügung stehen und das 32. (vorderste) Bit speichert, ob wir es mit einer positiven oder negativen Zahl zu tun haben. Der 1.1.1970, 0:00:00 Uhr entspricht der 0000 0000 0000 0000 0000 0000 0000 00002 – eine Zahl mit 32 Nullen. Seit diesem Datum wird dieser Zähler unablässig erhöht, jeweils um 1 in jeder Sekunde.

Wie wir aber wissen, sind Bitketten im Computer endlich – sie können nur bis zu einem bestimmten Wert zählen. Danach sind sie “voll” und es findet ein sogenannter Überlauf statt (ja, das heißt wirklich so). Ein Überlauf findet immer dann statt, wenn zu einer Zahl im Register des Prozessors eine weitere addiert wird, so dass das Ergebnis eine größere Zahl ist, als sie das Register überhaupt fassen könnte. Durch die Arbeitsweise der Rechenwerke von Computern führt ein Überlauf dazu, dass man, wenn man über die größtmögliche darzustellende  Zahl “hinausschießt”, im Bereich der kleinstmöglich darzustellenden Zahl landet. Die größte ganze Zahl, die sich mit 32 Bit darstellen lässt, ist die 2.147.483.647. Addiert man im Computer 1 zu ihr, landet man bei der -2.147.483.648, der kleinstmöglich darzustellenden ganzen Zahl.

Und genau das wird am 19. Januar 2038 um 03:14:08 Uhr passieren; dann erreicht der Zähler für die Sekunden seinen maximalen Wert – 0111 1111 1111 1111 1111 1111 1111 1111 11112 (das vorderste Bit ist das Vorzeichenbit) – und er wird umschlagen auf die nächste Zahl, die 1000 0000 0000 0000 0000 0000 0000 00002 (die kleinstmöglich darstellbare ganze Zahl mit 32 Bit). Rechnet man diese Zahl in ein Datum um, so ergibt sich der 13. Dezember 1901, 20:45:52 Uhr. Wer sich jetzt übrigens fragt, warum der Sekundenzähler als vorzeichenbehaftete Zahl implementiert wurde, wo doch das Vorzeichen dazu führt, dass bereits 2038 die höchstmögliche Zahl erreicht wird: das wurde festgelegt, um auch Zeiten vor dem 1.1.1970 über den Sekundenzähler darstellen zu können, was sonst ja nicht möglich gewesen wäre.

Das Jahr-2038-Problem könnte kritischere Auswirkungen als das Jahr-2000-Problem haben, da bei letzterem lediglich Systeme betroffen waren, die Jahreszahlen in dem beschriebenen 2-Ziffern-Format abgespeichert haben. Der Überlauf des Sekundenzählers wirkt sich dagegen auf alle Systeme aus, die in irgendeiner Weise auf ein vom Computer geliefertes Datum oder eine Zeit zurückgreifen, und das sind ziemlich viele.

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:

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.