Y2K-Problem: Warum überhaupt? Seit wann werden Zahlen dezimal gespechert?
-
Marc++us schrieb:
Es gab gar kein y2k-Problem. Es gibt aber bald ein y2k38-Problem.
Hä 2^11 = 2048 und wieso 11 Zeichen? wohl eher ein Y64K Problem
-
Wenn der Super-GAU auch real ausblieb, aber wieso gab es überhaupt diesen Hype? Wie gesagt: Sind die Zahlen nicht sowieso binär gespeichert, so dass auch theoretisch erst mit dem Wert 256 ein Problem auftreten würde?
-
Das Problem war, dass die jahreszahlen nur zweistellig abgespeichert wurden aus Platzgründen. Und 00 wurde eben in manchen Fällen als 1900 interpretiert und nicht als 2000.
-
J.Wayne schrieb:
Marc++us schrieb:
Es gab gar kein y2k-Problem. Es gibt aber bald ein y2k38-Problem.
Hä 2^11 = 2048 und wieso 11 Zeichen? wohl eher ein Y64K Problem
Das Problem ist, dass die meisten C/C++ Programme intern "time_t" verwenden... und der geht nur bis 2038...
-
Ja, aber das dürfte doch nur die Darstellung betreffen und nicht die interne Speicherung. Als was wurde der Jahreszahlenwert denn gespeichert? Als ein Byte? Dann hätten wir die Werte von 0 bis 255. Auch wenn dann bei Anzeigen 00 steht, dürfte der PC doch trotzdem keine Rechenfehler machen, da intern alles korrekt ist (oder zumindest zum Teil, wenn das Jahr 1999 für den Computer 99 ist, dann ist 2000 für ihn 100). Erst im Jahr 2156 wäre dann der Überlauf geschehen und damit die Rechenfehler und Fehlinterpretationen der Programme.
-
Nachtrag: Mein letzter Beitrag beog sich auf den Satz von Luckie:
Das Problem war, dass die jahreszahlen nur zweistellig abgespeichert wurden aus Platzgründen.
-
Marc++us schrieb:
Es gab gar kein y2k-Problem. Es gibt aber bald ein y2k38-Problem.
Ja, das könnte interessant werden.
Ich hab damals, als mir das das erste Mal auffiel, nen Kollegen gefragt, was der da machen wird. Antwort war: "Da bin ich in Rente, und wenns mein erster Tag ist!"
-
Bis dahin sind diese unsicheren C++ Programme sowieso durch Java Programme ersetzt worden.
-
Jochen Kalmbach schrieb:
Marc++us schrieb:
Es gab gar kein y2k-Problem. Es gibt aber bald ein y2k38-Problem.
Und das wird zu einer wirklichen Katastrophe! Da war das Y2k überhaupt nix dagegen...
Ganz zu schweigen davon dass in der *nix-Welt dies noch nicht mal registriert wurde...Wir ham ja noch 32 Jahre Zeit^^
-
Jochen Kalmbach schrieb:
Das Problem ist, dass die meisten C/C++ Programme intern "time_t" verwenden... und der geht nur bis 2038...
geht zur zeit bis 2038. gegen 2018 wird time_t auf 64 bit hochgeschraubt und gut ists. wo ist das problem?
-
volkard schrieb:
Jochen Kalmbach schrieb:
Das Problem ist, dass die meisten C/C++ Programme intern "time_t" verwenden... und der geht nur bis 2038...
geht zur zeit bis 2038. gegen 2018 wird time_t auf 64 bit hochgeschraubt und gut ists. wo ist das problem?
Da geb ich dir echt...wen das nicht shcon mit dem nächsten C++ STD
schon eingeführt wird.aber auf jedenfall wird ischs VOR 2038 ändern...
-
Das Problem war nicht die interne Speicherung, sondern die Interpretation. Nehmen wir an, es wurde in einen String umgewandelt und dann wieder zurück, was dann? Oder wenn der Benutzer 00 eingegeben hat, was war nun gemeint? 2000 oder doch 1900? Ein Kind welches 2000 geboren wurde hätte da wahrscheinluich Rente bekommen, weil das programm annimmt es sei 1900 geboren worden und damit schon im Rentenalter.
-
Ja, das macht Sinn.
-
shade37337 schrieb:
volkard schrieb:
gegen 2018 wird time_t auf 64 bit hochgeschraubt und gut ists. wo ist das problem?
Da geb ich dir echt...wen das nicht shcon mit dem nächsten C++ STD
schon eingeführt wird.tut im standard gar nicht nötig sein. time_t kann doch ruhig implementierungsabhängig bleiben.
-
volkard schrieb:
Jochen Kalmbach schrieb:
Das Problem ist, dass die meisten C/C++ Programme intern "time_t" verwenden... und der geht nur bis 2038...
geht zur zeit bis 2038. gegen 2018 wird time_t auf 64 bit hochgeschraubt und gut ists. wo ist das problem?
Ein Problem entsteht, wenn im Jahre 2017 Programme ausgeliefert wurden und diese nie wieder upgedatet werden (ja, sowas soll es geben).
-
Y2K schrieb:
Ist die Jahreszahl nicht binär gespeichert?
Der Kandidat erhält 100 Punkte!
-
Jochen Kalmbach schrieb:
volkard schrieb:
Jochen Kalmbach schrieb:
Das Problem ist, dass die meisten C/C++ Programme intern "time_t" verwenden... und der geht nur bis 2038...
geht zur zeit bis 2038. gegen 2018 wird time_t auf 64 bit hochgeschraubt und gut ists. wo ist das problem?
Ein Problem entsteht, wenn im Jahre 2017 Programme ausgeliefert wurden und diese nie wieder upgedatet werden (ja, sowas soll es geben).
sag mal..verwewndest du 20 jahre alte progs OHNE emu???
geht au nimma heutzutage....weil in der zeit die CPu reg-Size ungefähr ver 4 fahct wird....
-
shade37337 schrieb:
sag mal..verwewndest du 20 jahre alte progs OHNE emu???
Auf den Grossrechnern laufen teilweise Programme (oder Programmteile) die älter sind...
-
sag mal..verwewndest du 20 jahre alte progs OHNE emu???
geht au nimma heutzutage....weil in der zeit die CPu reg-Size ungefähr ver 4 fahct wird....[/quote]
Und auf deutsch?2038 werden alle Atomraketen sich selbstständig starten, weil sie nicht mehr wissen wie spät es ist. Und auch alle anderen Programme die garkeine Zeit benötigen werden nicht mehr funktionieren.
-
Bis 2038 sind wir doch eh schon tot wegen der Klimaerwärmung, dem dritten Golfkrieg bzw. dme ersten Südostasienkrieg (Iran und Nordkorea gegen den Rest der Welt), oder leben in einer virtuellen Welt und sind an ein Lebenserhaltungssystem angeschlossen, das ausserdem aus unseren Körperwärme Energie gewinnt..
Und ansonsten gibts bestimmt schon 128 oder mehr -bit Architekturen.
