Y2K-Problem: Warum überhaupt? Seit wann werden Zahlen dezimal gespechert?
-
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.
-
Ich werde meine Rechner jetzt nicht mehr updaten. Und dann lass ich ihn bis 2038 laufen und dann zerstört er die Welt. MUHAHAHAHA...
-
Ist eigentlich irgendwas passiert bei der 2000 Umstellung? Kann mich an die Sylvesternacht nicht mehr so gut erinnern
-
ausserdem besteht immerhin noch ein gewisse wahrscheinlichlichkeit dass der
bursche hier 2036 einschlägt:http://de.wikipedia.org/wiki/Apophis_(Asteroid)
was evtl. grössere probleme bereiten wird ...
-
Cpp_Junky schrieb:
Ist eigentlich irgendwas passiert bei der 2000 Umstellung? Kann mich an die Sylvesternacht nicht mehr so gut erinnern
In Deutschaand war das wirklich grosse "Ereigniss" der Totalzusammenbruch des Feuerwehr-/Rettungsdienst-Leitsystems in Berlin (siehe c't 13/00 bzw.
http://www.heise.de/ct/01/05/035/default.shtml
)
Was dazu geführt hat, dass die Leitstelle die Feuerwehr-/Rettungsfahrzeuge auf "Streife" geschickt hat um "zufälligerweise" die Unfälle zu finden... so kam es aber trotzdem vor, dass mehrere Stunden vergingen bis die Einsatzfahrzeuge am wirklichen Unfallort eintrafen...
-
estartu schrieb:
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!"
Ich hebe mir aus diesem Grund alle C-Compiler auf, die ich habe (schön redundant), damit ich zu diesem Zeitpunkt noch mal kurz 3 bis 400k einschieben kann, wenn sie dann alte C-Programmier brauchen, um die Programme zu fixen, analog zu der Cobol-Welle ab 1998. Ich bin dann 67, das passt perfekt.
[Das ist mein Ernst.]
-
Cpp_Junky schrieb:
Ist eigentlich irgendwas passiert bei der 2000 Umstellung? Kann mich an die Sylvesternacht nicht mehr so gut erinnern
Nein. Aber in der Zeit zwischen 1998 und 1999 war die Hölle los... der Markt für Freiberufler war wie leergefegt, und die Stundensätze verdoppelten und verdreifachten sich. Deswegen ist in der Sylvesternacht ja auch nix passiert.
-
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?
Volkard, ich bitte Dich... denk mal an die real existierenden Programme der real existierenden Programmierer. Zum einen haben Millionen von C-Programmierern nie time_t verwendet, sondern das Ding immer auf einen int32 gecastet, und dann gibt's Zillionen an Embedded-Systemen. Du weißt doch selbst, was heute noch für eine Code in C verzapft wird, die Sachen von heute laufen in 30 Jahren teilweise noch.
