Y2K-Problem: Warum überhaupt? Seit wann werden Zahlen dezimal gespechert?
-
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.
-
shade37337 schrieb:
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....Woher weiß denn der Emulator, daß diese eine 32-Bit-Adresse jetzt ein time_t ist? Und selbst wenn Du alle Adressen verdoppelst, dann ist es ja schön, daß Dein Speicher den Überlauf richtig macht, die Applikation kann aber damit immer noch nichts anfangen.
So einfach ist das auch wieder nicht. Eine Datenbank aufbohren auf das breitere Format ist noch relativ einfach, aber eine compilierte Anwendung insitu ist schon eine ganz andere Sache. Vor allem, wenn die letzte Doku dazu vor 15 Jahren in den Müll geworfen wurde.
-
Und sowas willst du dann in 30 Jahren bearbeiten? Da kauf ich mir lieber n paar Aktien und mach damit das große Geld
-
DeinErnst schrieb:
Und sowas willst du dann in 30 Jahren bearbeiten? Da kauf ich mir lieber n paar Aktien und mach damit das große Geld
das aufheben ist doch kein aufwand nicht. betrachten wir mal nur projekte, wo der sorce-code verfügbar ist. und es geht nicht ums echte bearbeiten, sondern nur darum, ein paar kleine offensichtliche fehler zu jagen und zu beheben und jemandem, der verdammt drauf angewiesen ist, es entsprechend in rechnung zu stellen. die aufrufe von time() und konsorten sind vermutlich nicht gerade oft. eigener code überschreibt library-code, also reicht es vielleicht schon, im eigenen code time() zu reimplemetieren, daß es statt 0=1.1.1970 mit 0=1.1.1970+X ist. und noch ein paar anpassungen und datenkonvertierungen. kann ja sein, daß man da für einen tag arbeit zwei wochen in rechnung stellen kann. die schwierigen jobs muss man nicht machen. der witz am aufheben ist, daß man der einzige ist, der es überhaupt machen kann.
bei deinem aktienkauf, vergiss also nicht, auch ein paar pakete marc++us-aktien zu kaufen.
-
Marc++us schrieb:
So einfach ist das auch wieder nicht. Eine Datenbank aufbohren auf das breitere Format ist noch relativ einfach, aber eine compilierte Anwendung insitu ist schon eine ganz andere Sache.
Aber in situ-Hybridisierung ist doch heute gar kein Problem mehr, das lernt jeder Laborant, und sogar Studenten dürfen sich damit abgeben..
Jetzt mal im Ernst, glaubt ihr in 30 Jahren seid ihr noch am Coden? Da habt aber nicht grad hochgesteckte Ziele..
-
THX 1138 schrieb:
Marc++us schrieb:
So einfach ist das auch wieder nicht. Eine Datenbank aufbohren auf das breitere Format ist noch relativ einfach, aber eine compilierte Anwendung insitu ist schon eine ganz andere Sache.
Aber in situ-Hybridisierung ist doch heute gar kein Problem mehr, das lernt jeder Laborant, und sogar Studenten dürfen sich damit abgeben..
Jetzt mal im Ernst, glaubt ihr in 30 Jahren seid ihr noch am Coden? Da habt aber nicht grad hochgesteckte Ziele..Was hast du gg Coden? Mir macht das Spass ohne Ende
