Diskussion:Jahr-2000-Problem/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Jahr-2000-Problem/Archiv#Thema 1]]

oder als Weblink zur Verlinkung auVorlage:SSerhalb der Wikipedia

https://de.wikiup.org/wiki/Diskussion:Jahr-2000-Problem/Archiv#Thema_1

QS nötig!!

Geneuere Recherchen zu Problematik und Lösungen nötig. Quellen! Kosten für die Wirtschaft (alles in IT-Literatur, "Datamation" usw.) nachlesbar! --Cami de Son Duc 13:40, 13. Mai 2009 (CEST)

Wie wäre es mit einem Einschub nach dem ersten Ursachenabsatz ala folgendem? (erl.)

Dies zumindest ist die weit verbreitete öffentliche Begründung. Tatsächlich ist es aber für einen Computer eher ungünstig, Zahlen im Dezimalsystem zu speichern, da sie für jede Rechnung in das Binärsystem umgewandelt werden müssen, das Computer intern verwenden. Zudem beansprucht die Speicherung von Dezimalzahlen unnötig viel Platz, da sie nicht genau in die allgegenwärtige Einteilung der Datenspeicher in Bytes zu je 8 Bit passen. Die Unixzeit, die schon Ende der 60er Jahre entstand, speichert zum Beispiel die Sekunden seit dem 1.1.1970 binär in 32 Bit, wodurch erst im Jahr 2038 ein Problem auftritt. Das Problem bestand folglich wahrscheinlich statt bei der Speicherung eher bei der Ein- und Ausgabe, für die in oder aus einem menschenlesbaren Datum konvertiert werden musste. Um Schreibplatz zu sparen nutzen Menschen noch heute oft nur die letzten beiden Ziffern der Jahreszahl. Wird ein Datum auf diese Weise eingegeben oder eingescannt, kommt es zu Fehlern, da die wenigsten Programme bei der Verarbeitung einer Eingabe das aktuelle Datum berücksichtigen. Auch machten es sich Programmierer bei der Ausgabe eines Datums oft zu einfach - manche Programme gaben im Jahr 2000 als Jahreszahl 19100 aus. Die interne Darstellung des Jahres wurde also in Jahre umgerechnet, denen eine 19 vorangestellt wurde. Dies ist zwar falsch, aber der Computer kann in diesem Fall intern noch korrekt weiterrechnen, da offensichtlich kein Speicherüberlauf aufgetreten ist und das aktuelle Datum nicht mit einem früheren verwechselt wird. -- RoKo 02:34, 6. April 2005 (CET)

Absatz entfernt (erl.)

Ich habe folgenden Absatz aus den Artikel entfernt:

Ein weiteres Problem im Jahr 2000 war, dass man dieses Jahr als Schaltjahr erkennen musste. Normalerweise sind durch 100 teilbare Jahre keine Schaltjahre, außer wenn sie durch 400 teilbar sind, wie in diesem Fall. Viele Computerprogramme mussten also entsprechend korrigiert werden. Technisch bedeutete das aber im Fehlerfall lediglich eine Abweichung von einem Tag.

Begründung: Dieses Problem gab es einfach nicht. Jemand der die Schaltjahre naiv implementiert macht einfach alle vier Jahre ein Schaltjahr. Jemand der die Ausnahme mit den 100ern kennt, hat sich informiert und wird deshalb auch die Ausname von der Ausname, nämlich die 400er kennen und entsprechend implementieren. In beiden Fällen wird das Jahr 2000 korrekt (wenn im ersten Fall auch nur zufällig) als Schaltjahr erkannt. Ich behaupte mal einfach, daß niemand so blöd ist, die 100er-Ausname zu implementieren und die 400er-Ausname nicht. -- MlaWU 14:45, 21. Jan 2006 (CET)

Nein, es gibt immer noch etwas Schlimmeres. Ich habe gut ein Dutzend Schaltjahrstabellen der Form 80,84,88,92,96,04,08 ändern lassen. Bis Mitte der neunziger Jahre war nicht zweifelsfrei allen bekannt, dass modulo 4 genügt. Ich möchte den Absatz wieder aufnehmen. Gfis 17:38, 14. Sep. 2008 (CEST)

Ich muss MlaWU recht geben.... Mit Schaltjahren hatte das Jahr-2000-Problem absolut nichts zu tun! Das Problem war, das Berechnungen vom aktuellen Datum zu einem Datum vor dem Jahrtausendwechsel einen negativen Wert ergeben könnten.

Beispiel:

Von 1997 zu 1999: 99-97 = 2

Von 1997 zu 2001: 01-97 = -96 (Ein System das keine negativen Zahlen hätte verarbeiten können, hätte hier anstelle einer Differenz von 4 Jahren, eine Differenz von 96 Jahren berechnet!)

--Martin38524 05:51, 8. Nov. 2008 (CET)

Sätze passen nicht

Aufgrund dieses Problems wurden, vor allem von wenig fachkundigen Menschen, im Vorfeld des Jahreswechsel 1999-2000 Katastrophenszenarien vorhergesagt, dass durch diesen Fehler Computerabstürze in großem Maß erfolgen würden und besonders sicherheitsrelevante Bereiche, die auf Computer angewiesen sind (Banken, Industrie oder auch Kraftwerke), durch das Problem lahmgelegt würden.

Ende der 90er-Jahre wusste eigentlich niemand mehr genau, inwiefern die ganze Y2K („Jahr 2000“)-Problematik von wirklicher Relevanz sein würde.

Diese beiden Sätze widersprechen sich. Entweder wussten die fachkundigen, dass das Y2K Problem keins sein wird, oder es wusste eben niemand... --[217.80.209.50] 23:45, 23. Jul. 2006

Die Aussage ist falsch, denn die Sätze widersprechen sich nicht! Es wusste zu KEINEM ZEITPUNKT jemand, "inwiefern die ganze Y2K („Jahr 2000“)-Problematik von wirklicher Relevanz sein würde". Im ersten Satz gibt es die Aussage dass diese "fachkundigen Menschen" nur Szenarien vorhersagten. Sie lieferten also nur Theorien, aber keine Beweise, weil sie nicht mit Sicherheit wussten was passieren würde. Diese Kernaussage findet sich auch im zweiten Satz, weil sie dort ebenfalls keine Beweise für ein wirkliches Problem hatten. Die technischen Aussagen beider Sätze sind also vom Prinzip her die gleichen, weshalb sich die Sätze auch nicht widersprechen.

Weil dieses Diskussionsthema seit 2,5 Jahren nicht begonnen wurde, sollte es gelöscht werden. --Martin38524 00:12, 29. Jan. 2009 (CET)

Letztlich ist der zweite Satz ein wenig unglücklich formuliert. Nichtsdestotrotz wurde das Thema begonnen und es gilt die generelle Regel, dass Diskussionsbeiträge nicht einfach gelöscht werden. Wenn Dir die Diskussionsseite zu voll erscheint, bitte eine automatische Archivierung in Erwägung ziehen. Gruß --Invisigoth67 (Disk.) 00:39, 29. Jan. 2009 (CET)

Neutralitaet? (noch lange nicht erl.)

"Aufgrund dieses Problems wurden, vor allem von wenig fachkundigen Menschen, im Vorfeld des Jahreswechsel 1999-2000 Katastrophenszenarien vorhergesagt [...]"

Ist zwar wahr, klingt in meinen Augen aber ziemlich unsachlich! serge 21:03, 14. Aug. 2007 (CEST)

Ich halte es für eine einzige große Lüge um Software zu verkaufen! Eben gerade weil es nur die letzten Zahlen hatte anstatt 4 Zahlen kann es einen solchen Fehler gar nicht geben.

Denn die Software wie Windows übernimmt die Datums Kakulation. Natürlich könnten auf älteren Betreibssystem oder Dos Anwendungen (wie man sie manchmal noch in Artzt Praxen und Bücherein sieht)Erst beim Wechseln von 31.12.9999 auf 01.01.10000 würde ein solcher Fehler auftreten.

Tatsächlich waren es nicht der PC sondern Software die keine Datum über 2000 einstellen konnte mit Problem. Dies war aber bei Windows in der Regel nicht Fall. Auf einen alten PC meiner Mutter lief auch Windows 98 ohne jedes Update.

Eben weil im Bios nur die Letzten Zahlen laufen und die 2 Ersten einfach +1 dazurechnen bei ereichen von 99 der letzten beiden Zahlen. 20 folgt nach 19 und wenn, die beiden letzten (Jahr und Jahrzehnt)Zahlen, 99 ereichen gibt das (Jahrhunderzahl+1) 20. Und dass geht so weiter bis 9999.

Da sieht man auch Mircosoft eine User den Xbox360 Acount bis 31.12.9999 gesperrt hat, weil eine höhrer Darstellung nicht möglich ist[1]--Dumah2008 21:24, 15. Sep. 2007 (CEST)

Du übersiehst, dass die IT Welt nicht nur aus Windows PCs besteht. 2000 erst recht nicht. Dass wirkliche Problem war, dass auf zahlreichen Grossrechnern Programme im Einsatz waren, die aus Zeiten stammten als Speicherplatz noch richtig Geld kostete. Die mussten vor allem untersucht und angepasst werden. Das Problem in einem PC die Jahreszahl hochzuzählen ist dagegen wirklich unwichtig. --Berthold Werner 11:10, 16. Sep. 2007 (CEST)

(Ich habe mal die Überschrift aktualisiert). Der ganze Artikel ist sehr laienhaft und vorurteilsbeladen... Ich bin in der passenden Altersgruppe (60+) und habe damals selbst an Projekten zur Rettung der Software mitgewirkt. Hier müsste wirklich mal sauber und neutral recherchiert werden! Die Wirtschaft hat damals weltweit Unsummen zur Rettung der Programme ausgegeben, und nicht nur, um IT-Firmen daran verdienen zu lassen. Die Gefahr war zu - sagen wir 50% - durchaus real. Es waren nicht nur (korrekt!) Großrechner mit COBOL & Co., sondern auch "embedded systems", also "Hardware" mit Mikroprogrammen. Wie hätten die hier gescholtenen Medien erst geheult, wenn massenweise 94jährige zur Einschulung ("6 Jahre alt!") bestellt worden wären. Soviel auch zum Thema (s.u.) "ist ja nix passiert!. --Cami de Son Duc 13:26, 13. Mai 2009 (CEST)

Aufzüge

Gibt's für das Abschalten von Aufzügen belastbare Quellen? --Berthold Werner 13:08, 5. Aug. 2008 (CEST)

Interpretation von zweistelligen Jahrzahlen

Hallo allerseits

Viele Systeme bilden die zweistellig gespeicherten Jahrzahlen gar nicht auf [1900,2000) ab, sondern auf [1950,2050) oder so ähnlich. Den genauen Bereich kenne ich nicht mehr, weiss nur noch, dass ich damals genau deshalb die Horrorszenarien als Unfug betrachtete. Heute weiss ich allerdings, dass es doch das eine odere andere :-) System gibt, welches 00 als 1900 interpretiert. Mich würde aber interessieren, in welchem Mass oben genannte Tatsache dazu beitrug, dass der Übergang ins 2000 so glimpflich verlaufen ist. Im Artikel wird sie gar nicht erst erwähnt. Weiss jemand etwas darüber? Je nachdem sollte das im Artikel noch ergänzt werden. --Chiccodoro 13:36, 19. Aug. 2008 (CEST)

Die genannte Bereichsverschiebung war eine Therapie des Problems, das Grenzjahr lag irgendwo zwischen 02 und 98, oft war es 50 oder 80. Gfis 17:38, 14. Sep. 2008 (CEST)

War es schlimm? Ist denn etwas passiert?

Zugegebenermaßen hat die Zunft der Softwerker mit dem Problem richtig gutes Geld verdient, und hatte deshalb kein Interesse, es kleinzureden. Der Beweis, dass auch dann nichts passiert wäre, wenn die Groß-EDV-Anwender (Banken, Versicherungen, Fluglinien, Kraftwerke ...) keine bis zu dreistelligen Millionenbeträge ausgegeben hätten, ist nie mehr zu erbringen, ähnlich war es bei der Euro-Umstellung (wobei dort teure Fehler eher bekannt wurden). Es wurde auch einige Software entsorgt und andere massiv renoviert.

Aber alle, die heute sagen: "Wie konnte man nur 2 Stellen benutzen!" frage ich: schreibt Ihr heute jede Jahreszahl mit 4 Stellen? Auch in Excel-Blättern, in jedem Datenbankfeld, bei der dir-Ausgabe - überall - gnadenlos, am besten gleich im sortierbaren ISO-Format (2008-09-14)? Ist Euch immer sofort klar, was eine Angabe 01/02/03 bedeutet? Es ist ja praktisch nichts passiert. Gfis 17:38, 14. Sep. 2008 (CEST)

...also ich kann mich noch genau an die "hiobsbotschaften" des millenniums entsinnen (obwohl ich da erst 11 war) ... in den monaten/wochen und tagen vor dem jahr 2000 haben viele medien (kann mich an rtl, pro 7 und ffh erinnern) wirklich unsicherheit und panik verbreitet. kurz vor dem milennium hieß es teils sogar, dass kernkraftwerke fehlgeschaltet werden könnten und so eine kernschmelze wie in tschernobyl eintreten könne und andererseits atomare raketen, die von russischer seite noch auf deutschland gerichtet seien, unwillkürlich starten könnten...(einfache stromausfälle wären da ja noch human gewesen) wahre schreckensszenarien waren nicht mehr theoretischen diskussionen unterworfen, sondern wurden dem volk unreflektiert "unter die nase gerieben"!

ich finde das war von medialer und journalistischer seite her wirklich eine schande!

... oder eine Leistung :-) Schliesslich ist man selber Schuld, wenn man den Medien alles ungefiltert und unüberprüft glaubt. --Chiccodoro 08:01, 24. Okt. 2008 (CEST)

Nicht nur die Medien haben da eine unrühmliche Rolle gespielt. Viele Horrorszenarien begannen mit: "Eine Studie hat gezeigt...."-- Kölscher Pitter 11:30, 24. Okt. 2008 (CEST)

Ich glaube in Thailand sind um Mitternacht einige Faxgeräte ausgefallen... Aber keine Sorge sobald die unixtime 2038 auf 0 schaltet geht die Welt unter... == 80.219.153.17 23:26, 10. Nov. 2009 (CET)

Mit Hexadezimalzahlen wäre es nie zu diesem Problem gekommen

Laut dem Artikel ist die Ursache für das "Jahr-2000-Problem", das die Programmierer für die Speicherung der Jahreszahlen nur die letzten beiden Ziffern (Jahr und Jahrzehnt) verwendet haben. Für die Speicherung der Jahreszahl sollten wohl nur 2 Bytes verwendet werden, um dadurch Speicherplatz zu sparen. Der Denkfehler hierbei: Wenn man die Jahreszahl (eine Dezimalzahl) in eine Hexadezimalzahl umwandelt, dann wären für ihre Speicherung ohnehin nur 2 Bytes erforderlich gewesen, denn eine 2 Byte große Hexadezimalzahl kann jeden Wert zwischen 0 und 65535 enthalten!

Beispiel für unsere jetzige Jahreszahl:

2008 = HEX 07D8 = HEX 07 + HEX D8 = 7 + 216 = Byte-Wert(7) + Byte-Wert(216)

Für Ansicht, Änderung und Auswertung der Daten, hätte man diesen Code dann nur wieder in eine Dezimalzahl umwandeln müssen....

Der Grund dafür, warum man mit dieser Methode das "Jahr-2000-Problem" nie gehabt hätte liegt im Unterschied zwischen den Dezimal- und Hexadezimalzahlen. Beinhaltet ein Byte die einzelne Ziffer einer Dezimalzahl, dann kann es nur 10 verschiedene Zustände annehmen, die den Zahlen von 0 bis 9 entsprechen. Ein Byte besteht aber aus 8 Bit und kann 256 verschiedene Zustände annehmen, weil jedes einzelne Bit unhabhängig voneinander den Wert 0 oder 1 annehmen kann. Diese Kombinationen von Nullen und Einsen wird auch als Binärcode bezeichnet. Weil Hexadezimalzahlen alle 8 Bits eines Bytes benutzen, werden so zum Speichern von Zahlen weniger Bytes benötigt.

Hexadezimalzahlen bestehen aus 16 verschiedenen Zeichen. Den Zahlen von 0 bis 9 und anschließend den Buchstaben von A bis F. Für jedes Byte werden immer 2 dieser Zeichen für die Darstellung benötigt.

Beispiele:

0 = HEX 00 (1 Byte)

9 = HEX 09 (1 Byte)

10 = HEX 0A (1 Byte)

15 = HEX 0F (1 Byte)

16 = HEX 10 (1 Byte)

255 = HEX FF (1 Byte)

256 = HEX 0100 (2 Byte)

511 = HEX 01FF (2 Byte)

512 = HEX 0200 (2 Byte)

65535 = HEX FFFF (2 Byte)

Hier meine Frage an Euch:

Würde es Sinn machen dies im Artikel zu erwähnen? Das Problem: Man kann ja nur spekulieren warum die Programmierer diese Methode nicht benutzt haben!

Vom Grundsatz her gibt es hierfür aber nur zwei Erklärungen:

1. Sie sind einfach nicht auf diese Lösung gekommen.

2. Ihnen war der Aufwand zu groß.

Von der Logik her scheidet die zweite Erklärung aber aus, weil der Programmieraufwand mit einem Unterprogramm sehr gering gewesen wäre! Mit den folgenden zwei Unterprogrammen in der Programmiersprache BASIC, ist es sogar möglich jedes Datum zwischen dem 1.1.0 und dem 31.12.65535 mit nur jeweils 4 Byte zu codieren und dies selbstverständlich auch wieder rückgängig zu machen! Deshalb muss man wohl eher davon ausgehen, dass es den Programmierern damals einfach nur am technischen Wissen gemangelt hat....

Datum codieren (Beispiel: 8.11.2008 zu Byte-Wert 7 + 216 + 4 + 84)

codieren: tag=Val(datum$) datum$=Right$(datum$,Len(datum$)-Instr(datum$,".")) monat=Val(datum$) datum$=Right$(datum$,Len(datum$)-Instr(datum$,".")) datum$=Right$(Hex$(Val(datum$)),4) werth=Hex#(Left$(datum$,2)) wertl=Hex#(Right$(datum$,2)) datum$=Chr$(werth)+Chr$(wertl) werth=Hex#(Left$(Right$(Hex$(monat*100+tag),4),2)) wertl=Hex#(Right$(Right$(Hex$(monat*100+tag),4),2)) datum$=datum$+Chr$(werth)+Chr$(wertl) Return

Datum decodieren (Beispiel: Byte-Wert 7 + 216 + 4 + 84 zu 8.11.2008)
decodieren: jahr=Hex#(Right$(Hex$(Asc(Left$(datum$,1)))+Right$(Hex$(Asc(Mid$(datum$,2,1))),2),4)) tag=Hex#(Right$(Hex$(Asc(Mid$(datum$,3,1)))+Right$(Hex$(Asc(Right$(datum$,1))),2),4)) monat=Int(tag/100) tag=tag-monat*100 datum$=Str$(tag)+"."+Str$(monat)+"."+Str$(jahr) Return

Das für den Tag und den Monat zusammen ebenfalls nur 2 Byte erforderlich sind liegt daran, weil beide Zahlen zu einer verschmolzen werden, in der die Monate die Wertigkeit der Hunderter haben und die Tage ihre Wertigkeit behalten.

Beispiel:

8.11. (8 November) = 8 + 11*100 = 1108

Diese Dezimalzahl kann natürlich ebenfalls in eine Hexadezimalzahl umgewandelt werden....

1108 = HEX 0454

Deshalb werden zum speichern des Tages und des Monats zusammen ebenfalls nur 2 Bytes benötigt.

HEX 0454 = HEX 04 + HEX 54 = 4 + 84 = Byte-Wert(4) + Byte-Wert(84)

Dieses in einem 4 Byte (32 Bit) großen Code codierte Datum, kann man sogar direkt im Binärcode sortieren, weil die Bits folgendermaßen angeordnet sind: 1 bis 16 (Jahr), 17 bis 24 (Monat) und 25 bis 32 (Tag) / Entspricht beim 8.11.2008: 20081108

Hätte man das Problem mit dem Speicherplatz damals so gelöst wie ich es hier beschrieben habe, dann hätte man sogar noch zusätzlichen Speicherplatz sparen können und es hätte das "Jahr-2000-Problem" niemals gegeben! --Martin38524 03:44, 8. Nov. 2008 (CET)

... welches es ja so oder so nicht real gegeben hat ;) -- [79.199.228.25] 01:05, 12. Nov. 2008

Selbstverständlich war das ein Problem! Die Umrüstung von Steuerungen und Software, hat der Weltwirtschaft mit Sicherheit einen finanziellen Schaden (Kosten) von einigen Milliarden verursacht. Eine Änderung, beziehungsweise Erweiterung, ist schließlich immer mit Kosten verbunden. Mir sind hierfür zwar keine Quellen bekannt, aber es ist ja allgemein bekannt, das es solche Änderungen gegeben hat. --Martin38524 18:34, 14. Nov. 2008 (CET)

Hätte, wenn .. wäre??? Als die Computer das Laufen lernten, hat sich niemand dafür interessiert. Es gab reichlich andere Probleme.-- Kölscher Pitter 11:43, 12. Nov. 2008 (CET)

Aber man hätte darauf kommen MÜSSEN, das dies später ein Problem geben würde. Und wenn man Speicherplatz sparen will, dann sollte man sich doch wohl Gedanken machen, wie das RICHTIG zu erreichen ist! --Martin38524 19:39, 12. Nov. 2008 (CET)

Soviel ich weiß, haben die Programmierer anno dazumal sehr wohl die Methode der Umrechnung eines dezimal dargestellten Datums auf Binär/Hexadezimal angewandt. Selbst bei einer simplen Umrechnungsroutine ergab das einen Verbrauch von 5 Bit für den Tag, 4 für den Monat und 7 für das zweistellige Jahr. Macht in Summe 16 Bit, also 2 Byte. Bei einer vierstelligen Jahreszahl wäre man um ein drittes Byte nicht herumgekommen, und das wollte man damals offenbar vermeiden, da Speicherplatz gering und teuer war. Wenn damals tatsächlich jemand Zahlen unkomprimiert gespeichert hätte, wäre er vermutlich vom Rechenzentrumsleiter mit einem Stapel Lochkarten erschlagen worden. ;-) Und wahrscheinlich dachte in den 60er und 70er Jahren niemand daran, dass eines der Programme Jahrzehnte später noch laufen würde, und die Programmier- und Umrechnungsmethoden wurden einfach weitergereicht und von der nächsten Generation an Programmierern übernommen... Gruß --Invisigoth67 (Disk.) 20:26, 14. Nov. 2008 (CET)

Ich halte die Geschichte um den gespeicherten teuren Speicherplatz für ein Märchen. Gespart wurde an etwas ganz anderem und zwar an der Tipparbeit für 4- statt 2-stellige Jahreszahlen. Man muß sich doch nur die Datumsangaben anschauen, die Leute zu Papier bringen. 4-stellige Jahreszahlen schreibt fast niemand.

Speicherplatz war seinerzeit immens teuer, nicht nur, dass eine Festplatte von der Größe einer Waschmaschine nur ein paar hundert Megabyte (die genaue Zahl hab' ich vergessen) speichern konnten, die hatten zudem einen hohen Stromverbrauch, der sich noch dadurch drastisch erhöhte, dass sie in klimatisierten Räumen betrieben werden mußten. Man hatte also nicht nur hohe Anschaffungskosten, sondern auch hohe Betriebskosten in Form von Stromverbrauch und belegtem Platz. Als ich vor über 20 Jahren meine Arbeit in einem Rechenzentrum begann waren dort Festplatten dieses Waschmaschinenkalibers auf einer Fläche wie einer Turnhalle aufgebaut und die hatten zusammen gerademal ca.50 GByte. Das war damals für einen PC Besitzer geradezu unvorstellbar viel, mein Pc hatte damals glaube ich eine 20 oder 60 MByte Festplatte. Übrigens programmierte man zu der Zeit im Großrechnerbereich praktisch ausschließlich in COBOL, da gab es die Möglichkeit die Datendeklaration so zu machen, dass möglichst wenige Bytes belegt wurden. Für eine Zahl im Bereich 0-99 wurde dann auch nur ein Byte im Speicher und der Datenbank belegt. --Berthold Werner 13:16, 28. Dez. 2008 (CET)

@Martin38524: Was Deine "erledigt"-Edits betrifft: Wenn es Dein Wunsch ist, darzulegen, dass Du nichts mehr zu diesem Diskussionsabschnitt beitragen möchtest, könntest Du das ja in Form eines (von Deiner Seite abschließenden) Kommentars tun. Was die automatische Archivierung betrifft, siehe oben. Wähle ein Archivierungskonzept, stelle es hier zur Diskussion, und nach positiver Bewertung kann es umgesetzt werden. Gruß --Invisigoth67 (Disk.) 01:24, 29. Jan. 2009 (CET)

Jahr-2010-Problem

Offenbar gab es nach dem Jahreswechsel auf 2010 eine Reihe unerwarteter IT-Probleme, siehe: http://www.heise.de/newsticker/meldung/Das-Jahr-2010-sorgt-fuer-IT-Probleme-895399.html Nach meiner Erinnerung sind sie sogar stärker als seinerzeit beim 2000er-Wechsel. Im Gegensatz dazu gab es im Vorfeld des Jahreswechsels auf 2010 praktisch keine öffentliche Sensibilisierung für das Problem und es wurde offenbar auch in der Fachwelt unterschätzt. Im Nachhinein aus meiner Sicht eine schöne Bestätigung, dass der große Aufwand vor dem Jahre 2000 gerechtfertigt war und größere Probleme vermieden hat. Sollte man zum Jahr-2010-Problem vielleicht hier einen Absatz einbauen? Für einen eigenen Artikel genügt es wohl nicht. --Thomas Binder, Berlin 10:47, 5. Jan. 2010 (CET)

Nun ja, im Prinzip haben diese "2010-Problemchen", die allesamt harmloser als die div. Y2K-Probleme ausgefallen sind, nur bedingt mit Y2K zu tun, da hier schlicht andere Programmierfehler und Versäumnisse geschehen sind. Auch bei normalem Jahreswechsel, der Sommerzeit-Umstellung und am 29. Februar in Schaltjahren kommt es in manchen Computersystemen zu Problemen, aber all das hält sich in Grenzen. Solange die öffentliche Wahrnehmung nicht weit über den heise-Newsticker-Artikel hinausgeht, ist das m.E. enzyklopädisch nur minder relevant. Vollste Zustimmung jedenfalls, dass der Aufwand vor dem Jahr 2000 gerechtfertigt war, denn hätte man damals nicht rechtzeitig mit der Y2K-Bug-Prevention begonnen, hätte gröberes passieren können. --Invisigoth67 (Disk.) 12:12, 5. Jan. 2010 (CET)

Naja, die öffentliche Wahrnehmung geht schon über Heise hinaus. Einzelfälle (vor allem mit den Geldautomaten) haben es in die Tagespresse und Nachrichtensendungen geschafft. Mich wundert, dass man durch das damalige Y2K-Thema nicht sensibler geworden ist. Die Leute, die heute entwickeln bzw. Verantwortung tragen, werden auch Y2K zumindest schon wahrgenommen haben. Und die jetzigen - in der Tat viel kleineren - Problemchen wären sicher auch mit viel kleinerem Aufwand vermeidbar gewesen. --Thomas Binder, Berlin 13:12, 5. Jan. 2010 (CET)

"Some Y2K fixes in 1999 were real quick-hacks. For example a logic like this could have been applied: IF YEAR < 10 THEN YEAR = YEAR + 2000 ELSE YEAR = YEAR + 1900. Hacks like that would create problems now, in 2009 and 2010." (sic) (nicht signierter Beitrag von 84.62.221.194 (Diskussion | Beiträge) 20:35, 5. Jan. 2010 (CET))

Zugegeben, aufgrund der Medienberichte der letzten 2 Wochen war es doch gar kein so verniedlichebares Problem"chen". Hat daher mittlerweile auch schon ein eigenes Lemma: Jahr-2010-Problem. --Invisigoth67 (Disk.) 13:05, 15. Jan. 2010 (CET)

Autobusfahrscheinbestätigungsmaschinen

Autobusfahrscheinbestätigungsmaschinen??? Geht's noch länger? --89.246.12.213 15:52, 2. Okt. 2012 (CEST)

Ich vermute, gemeint sind die Fahrscheinentwerter. Bekloppte Wortschöpfungsarie. Habe es aber nicht geändert, da ich Australien nicht kenne und es etwas ganz anderes sein könnte.--78.53.46.51 12:57, 1. Jan. 2013 (CET)

Schaltjahre

Im Artikel steht:

Nicht direkt damit zusammenhängend, aber nötigenfalls oft gleichzeitig behoben oder kontrolliert wurde eine manchmal unbeachtete Schaltjahr-Regelung des Gregorianischen Kalenders. Nach dieser sind runde Jahrhunderte keine Schaltjahre, außer sie sind durch 400 ganzzahlig teilbar, was nach 1600 erst 2000 wieder der Fall war.

Ich verstehe nicht, inwiefern das ein Problem für das Jahr 2000 sein könnte. Wenn in der Software auf die Einprogrammierung dieser Spezialregel verzichtet wurde, dann gibt es doch erst 2100 ein Problem und nicht im Jahre 2000, denn 2100 kommt das erste Jahr, das durch 4 teilbar ist aber kein Schaltjahr ist seitdem es Computerprogramme gibt. Wurde diese Sonderregel jedoch von Anfang an einprogrammiert, so gibt gar keine Probleme, auch nicht 2100. Also was ist der Punkt? --Jobu0101 (Diskussion) 19:00, 1. Jul. 2013 (CEST)

Wenn bei der programmierten Schaltjahrberechnung zwar die 100-Jahre-Regel, aber nicht die 400-Jahre-Regel berücksichtigt worden wäre, dann hätte es ein Problem gegeben. Was angeblich vereinzelt, aber halt nur sehr vereinzelt, der Fall war. --Invisigoth67 (Disk.) 19:26, 1. Jul. 2013 (CEST)

Das stimmt natürlich, aber das ist schon ziemlich dämlich als Programmierer, die 100-Jahre-Regel zu implementieren, wenn beim nächsten Jahrhundertwechsel die 400-Jahre-Regel greifen müsste. Denn so kommt es zu keiner einzigen korrekten Anwendung der 100-Jahre-Regel, also hätte man sich die Implementierung auch sparen können. Aus heutiger Sicht hingegen könnte man die Implementierung der 100-Jahre-Regel ohne die 400-Jahre-Regel rechtfertigen, da damit die Lebensdauer der Software um 300 Jahre verlängert wird. --Jobu0101 (Diskussion) 23:21, 1. Jul. 2013 (CEST)

Soweit ich mich erinnern kann, lag es damals (also in den 70er oder 80er Jahren) nicht daran, dass man aus Faulheit auf die Implementierung der 400-Jahre-Regel verzichtet hat, sondern vielmehr daran, dass ein paar Programmierer zwar von der 100-Jahre-Regel, nicht aber von der 400-Jahre-Regel wussten. "Im Internet nachschauen" gab's damals nicht, und wenn die Kollegen behauptet haben, es gäbe nur die 4- und 100-Jahre-Regel, hat man das eben so programmiert. Und auch aus heutiger Sicht ist die Implementierung der 400-Jahre-Regel insofern sinnvoll, da mit ihr die Software rein theoretisch ewig korrekt läuft, ohne ihr hingegen nur bis 2400. --Invisigoth67 (Disk.) 05:36, 2. Jul. 2013 (CEST)

Was sollen diese Spekulationen: (Das Jahr) 2000 ist durch 400 teilbar, also gilt die Ausnahme von der Ausnahme. Wenn man für dieses Jahr zum Beispiel einen Tagezeitraum berechnen will, muss(te) die 400-Jahre-Regel passen, sonst wirds falsch. Da muss man nicht bis zum Jahr 2400 warten. Außerdem gibts hier in der Disk einen Denkfehler: Der Jahr 2000-Fehler trat ja nicht nur genau am 1.1.2000 auf, sondern wenn ein Programm über diesen Zeitpunkt hinaus rechnet, egal ob das vor oder nach dem 1.1.2000 geschieht. So ist es auch mit der 400er Regel. --VÖRBY (Diskussion) 09:05, 2. Jul. 2013 (CEST)

Du schriebst:

Wenn man für dieses Jahr zum Beispiel einen Tagezeitraum berechnen will, muss(te) die 400-Jahre-Regel passen, sonst wirds falsch.

Das stimmt nur, wenn man die 100-Jahre-Regel implementiert hat. Dennoch ist es natürlich richtig, dass Software, die nicht nur mit dem aktuellen Datum arbeitet, sondern auch mit alten und zukünftigen Daten, besser alle Regeln implementiert haben sollte. --Jobu0101 (Diskussion) 09:49, 2. Jul. 2013 (CEST)

Damit sollten alle Unklarheiten und etwaigen Denkfehler nun behoben sein. Eine datums-/zeitraumberechnende Software, die alle Schaljahrregeln bis auf die 400-Jahre-Regel berücksichtigt, hätte mit der Berechnung von Zeiträumen, die einen Schalttag der 400-Jahre-Regel beinhalten, ein Problem. Und genau das ist mit dem Satz im Artikel gemeint. --Invisigoth67 (Disk.) 20:33, 2. Jul. 2013 (CEST)

Anzeigetafel in Nantes

"In Frankreich in Nantes wurde auf einer Anzeigetafel das Datum 3. Januar 1900 angezeigt", heißt es im Artikel. War es denn am 1. und 2. Januar korrekt? Kommt mir unwahrscheinlich vor. --Schneid9 (Diskussion) 02:13, 11. Nov. 2013 (CET)

Dem stimme ich zu. Habe den Satz nun entfernt, da es sich bei den per Einzelnachweis belegten Bugs doch um etwas größere Probleme gehandelt hat, während falsche Anzeigen auf Displays doch um einiges häufiger anzutreffen waren. Die Bildunterschrift sollte reichen. Gruß --Invisigoth67 (Disk.) 08:13, 11. Nov. 2013 (CET)

Y3K

Und was ist mit Y3K ? siehe /var/log/messages :

kernel: [    1.113999] rtc0: alarms up to one year, y3k, 114 bytes nvram, hpet irqs

-- itu (Disk) 08:53, 20. Jan. 2016 (CET)

Was soll damit sein? Y3K ist nicht Y2K. WENN ein Programm über das Jahr 3000 hinaus rechnen sollte, dies aber nicht kann, weil es nicht "Y3K-compliant" ist, warum auch immer, wäre das einfach ein Programmfehler. Ansonsten wäre ein 'nicht über die Jahrtausendgrenze rechnen können' i.w.S. auch ein Y2K-Fehler.

PS: Was soll das mit der Zitrone in Deinen Disk-Beiträgen? Halte ich für seltsam. --VÖRBY (Diskussion) 16:26, 20. Jan. 2016 (CET)

Zuerst mal sollte Wikipedia erklären können was Y3K ist oder was es damit auf sich hat. Simple Annahmen ersetzen das nicht und erklären auch eine Sache nicht. -- itu (Disk) 16:13, 21. Jan. 2016 (CET)

Soll Wikipedia jede Abkürzung, die es irgendwo gibt, behandeln? M.W. war Y3K im IT-Bereich noch nie ein Thema - und wird es wahrscheinlich auch nicht mehr, wenn wir - als Menschheit - so weitermachen. :-( --VÖRBY (Diskussion) 17:23, 21. Jan. 2016 (CET)

Es ist mehr wie eine Abkürzung - jedenfalls solange du nicht definitiv herausfindest was sich dahinter verbirgt(beachte das vorher gesagte). -- itu (Disk) 18:00, 21. Jan. 2016 (CET)