de.wikipedia.org/wiki/Jahr-2038-Problem
HI
Muss man um dieses Problem zu beheben einen ganzen Code umschreiben oder reicht es wen die Server 64bit sind?
2038
gepostet vor 18 Jahre, 2 Monate von Sanni
gepostet vor 18 Jahre, 2 Monate von Kallisti
Meinst du, dein Spiel spielt in 32 Jahren noch jemand? :-)
Ansonsten sollte es wirklich reichen, es auf 64 Bit Hardware zu nutzen - du wirst ja eh die darunterliegenden Mechanismen verwenden (Linux/Unix, PHP, MySQL) und dir selbt wenig Gedanken machen.
Wer natuerlich in C/Java/etc. programmiert und die Zeit in 32 Bit Integern speichert, bekommt dann Probleme.
Ansonsten sollte es wirklich reichen, es auf 64 Bit Hardware zu nutzen - du wirst ja eh die darunterliegenden Mechanismen verwenden (Linux/Unix, PHP, MySQL) und dir selbt wenig Gedanken machen.
Wer natuerlich in C/Java/etc. programmiert und die Zeit in 32 Bit Integern speichert, bekommt dann Probleme.
gepostet vor 18 Jahre, 2 Monate von Klaus
Ich glaube 32 Jahre reichen um auf 128 Bit oder mehr zu wechseln.
gepostet vor 18 Jahre, 2 Monate von Todi42
Das ganze tritt aber auch nur bereits im Jahre 2038 auf, wenn der time_t als vorzeichenbehafteter Typ deklariert ist bei vorzeichenlosen typen, hat man 2^31 Sekunden mehr Zeit. Das ganze ist übrigens auf den zweiten Blick gar nicht so abstrakt, wenn man z.B. mal an die Laufzeiten bei Versicherungen denkt.
gepostet vor 18 Jahre, 2 Monate von Kampfhoernchen
Lösung: Timestamps jetzt schon als BigInt deklarieren.
PHP/Ruby is das recht einfach. Da muss nur ein Alter-Table laufen.
Typensichere Sprachen halt noch einmal ein Ersetzen von int durch long.
Bin mal gespannt ob sie dann wieder Atomraketen-Panik schieben wie 2000 (diesmal wohl eher bei den Amis mit ihren Unix-Timestamps - die Russen hab ja wohl eher nen DateTime verwendet).
PHP/Ruby is das recht einfach. Da muss nur ein Alter-Table laufen.
Typensichere Sprachen halt noch einmal ein Ersetzen von int durch long.
Bin mal gespannt ob sie dann wieder Atomraketen-Panik schieben wie 2000 (diesmal wohl eher bei den Amis mit ihren Unix-Timestamps - die Russen hab ja wohl eher nen DateTime verwendet).
gepostet vor 18 Jahre, 2 Monate von planetenkiller
Technisch betrachtet behebt die 64-Bit-Umstellung das Zeitstempelproblem nicht endgültig. Das Problem wird lediglich um etwa 290 Milliarden Jahre in die Zukunft verschoben.
Wenn wir das Jahr 2038 überschritten haben und dann alles (wieder^^/noch) geht, brauchen wir uns dann wenigstens keine sorgen mehr zu machen
gepostet vor 18 Jahre, 2 Monate von knalli
Original von planetenkiller
Technisch betrachtet behebt die 64-Bit-Umstellung das Zeitstempelproblem nicht endgültig. Das Problem wird lediglich um etwa 290 Milliarden Jahre in die Zukunft verschoben.
Wenn wir das Jahr 2038 überschritten haben und dann alles (wieder^^/noch) geht, brauchen wir uns dann wenigstens keine sorgen mehr zu machen
Prinzipiell eigentlich eine rationale Entscheidung. Wofür Sorgen machen? Entweder es funktioniert noch alles, oder.. naja, wen kümmerts dann noch?
War das jetzt zu viel Sarkasmus für einen Tag?
gepostet vor 18 Jahre, 2 Monate von HSINC
dann sollten wir uns aber auch gedanken um dieses problem machen
"Technisch betrachtet behebt die 64-Bit-Umstellung das Zeitstempelproblem nicht endgültig. Das Problem wird lediglich um etwa 290 Milliarden Jahre in die Zukunft verschoben."
"Technisch betrachtet behebt die 64-Bit-Umstellung das Zeitstempelproblem nicht endgültig. Das Problem wird lediglich um etwa 290 Milliarden Jahre in die Zukunft verschoben."
gepostet vor 18 Jahre, 2 Monate von TheUndeadable
Daher nutze ich den MySQL-Datentyp DATETIME bzw in C# den nativen Datentyp für Datumsangaben (DateTime)
Dieser Timestamp-Integer ist in meinen Augen sowieso etwas unsauber. Ich nutze lieber einen sauberen von der Programmiersprache bereitgestellten Datentyp. Meiner Meinung nach gab es mal einen in PHP, der aber wieder entfernt wurde. Ob dieser wieder neu eingebracht wurde, weiß ich nicht.
Dieser Timestamp-Integer ist in meinen Augen sowieso etwas unsauber. Ich nutze lieber einen sauberen von der Programmiersprache bereitgestellten Datentyp. Meiner Meinung nach gab es mal einen in PHP, der aber wieder entfernt wurde. Ob dieser wieder neu eingebracht wurde, weiß ich nicht.
gepostet vor 18 Jahre, 2 Monate von Sanni
nagut ich denke im jahr 2037 mache ich mir nochmal Sorgen vorerst sollte es ja gehe
gepostet vor 18 Jahre, 2 Monate von knalli
Original von Sanni
nagut ich denke im jahr 2037 mache ich mir nochmal Sorgen vorerst sollte es ja gehe
Das trauige ist, du wirst nicht der einzige sein, der sich 2037 dann mal langsam Sorgen drum macht. Weil, so plötzlich konnte damit ja keiner rechnen
gepostet vor 18 Jahre, 2 Monate von Sarge
und das schöne dadran ist.. für 90% der schnell lebigen software ist das auch egal das man sich vor 2032 sich keine gedanken drüber macht -.-
Für die restlichen 10% sollten dann die 5 jahre zur umstellung hoffentlich reichen.
Könnte aber wirklich interessante auswirkungen haben wenn plötzlich negative Zeitdifferenzen auftreten ich hoff meine bank hat bis dahin dran gedacht oder mein konto ist bei der zinsberechnung grad im minus O-)
Für die restlichen 10% sollten dann die 5 jahre zur umstellung hoffentlich reichen.
Könnte aber wirklich interessante auswirkungen haben wenn plötzlich negative Zeitdifferenzen auftreten ich hoff meine bank hat bis dahin dran gedacht oder mein konto ist bei der zinsberechnung grad im minus O-)
gepostet vor 18 Jahre, 2 Monate von Tetha
Original von TheUndeadable
Daher nutze ich den MySQL-Datentyp DATETIME bzw in C# den nativen Datentyp für Datumsangaben (DateTime)
Hatte Datetime nicht das J10k problem, weil dann die Jahre nicht mehr vierstellig sind?
gepostet vor 18 Jahre, 2 Monate von Störti
*Die Behauptung aufstell, dass uns das J10K-Problem nicht die Bohne interessiert*
Viele der neueren Server sind schon 64bit, und in 3-4 Jahren wird es keine 32bit Systeme mehr zu kaufen geben und bis wir im Jahr 2030 ankommen (wo das doch bald mal eine Rolle spielen könnte), ist jedes Programm schon mind. 64Bit-compiliert, vllt bauen die bis dahin auch schon 128Bit-CPU's, wer weiss...
Also darum würd ich mir null sorgen machen...
Viele der neueren Server sind schon 64bit, und in 3-4 Jahren wird es keine 32bit Systeme mehr zu kaufen geben und bis wir im Jahr 2030 ankommen (wo das doch bald mal eine Rolle spielen könnte), ist jedes Programm schon mind. 64Bit-compiliert, vllt bauen die bis dahin auch schon 128Bit-CPU's, wer weiss...
Also darum würd ich mir null sorgen machen...
gepostet vor 18 Jahre, 2 Monate von jonasq
wegen des J10k Problems:
meinst du nicht, daß du dich da etwas sehr aus dem Fenster lehnst?
meinst du nicht, daß du dich da etwas sehr aus dem Fenster lehnst?
gepostet vor 18 Jahre, 2 Monate von None
Als Berufstätiger Programmierer kann ich nur sagen, daß Software und Systeme in der Regel weit über das Datum hinaus noch aktiv sind, welches man als Abschalttermin definiert hat.
2038 mag zwar in relativ ferner Zukunft sein, aber sich heute schon darüber Gedanken zu machen ist nicht falsch.
Vom Y2K Problem wußten wir alle auch lange genug und wenn ich mir überlege was für eine Hektische Panik kurz vor Schluß losging...
2038 mag zwar in relativ ferner Zukunft sein, aber sich heute schon darüber Gedanken zu machen ist nicht falsch.
Vom Y2K Problem wußten wir alle auch lange genug und wenn ich mir überlege was für eine Hektische Panik kurz vor Schluß losging...
gepostet vor 18 Jahre, 2 Monate von Tetha
@jonas:
Sagen wir es mal so, ich denke eigentlich, dass - vor allem im Browsergamesbereich - alles vor 2030 zum thema 2038 aehnlich weit aus dem fenster gelehnt ist
Sagen wir es mal so, ich denke eigentlich, dass - vor allem im Browsergamesbereich - alles vor 2030 zum thema 2038 aehnlich weit aus dem fenster gelehnt ist
gepostet vor 18 Jahre, 2 Monate von None
Die meisten Server laufen ja schon auf 64 Bit Systemen. zwar wird das Problem nicht gelöst aber um ~290 Milliarden Jahre verschoben. und ich schätze so lang lebt kein Browsergame. Warum auch sorgen machen?
gepostet vor 18 Jahre, 2 Monate von TheUndeadable
Original von Tetha
Original von TheUndeadable
Daher nutze ich den MySQL-Datentyp DATETIME bzw in C# den nativen Datentyp für Datumsangaben (DateTime)
Hatte Datetime nicht das J10k problem, weil dann die Jahre nicht mehr vierstellig sind?
Ja, das gibt es. Sollte es aber soweit kommen, kann man DateTime einfach erweitern und das Projekt neukompilieren. Mit int als Timestamp ist es nicht möglich, da int auf 32-Bit festgefroren wurde.
gepostet vor 18 Jahre, 2 Monate von Kampfhoernchen
Und was lernen wir daraus? Java-Programme kann man 2038 wegwerfen, PHP nicht, da reicht PHP 120.4.5 RC1
gepostet vor 18 Jahre, 2 Monate von Todi42
Original von MrMarco
2038 mag zwar in relativ ferner Zukunft sein, aber sich heute schon darüber Gedanken zu machen ist nicht falsch.
Bis dahin bin ich in Rente :-)
gepostet vor 18 Jahre, 2 Monate von Kampfhoernchen
Gedanken machen?
Probieren geht über Studieren.
Hier mal ein Screenshot:
www.turbohummel.de/files/2070.png
Übrigens haben Firefox und IE7 ohne zu meckern den Dienst quitiert.
MaxDB, Cloudscape und MySQL haben sich klammheimlich davongeschlichen.
Oracle hat als Datum einfach nur 0 zurückgeliefert.
Beim zurückstellen der Zeit:
- Alle Kekse weg (shit!!!!!)
- Skype und Trillian abgestürzt
- Firewall meinte ich hätte versucht die Lizenz wiederrechtlich zu verlängern
- Winamp spielte Lieder mit doppelter Geschwindigkeit !??!
Probieren geht über Studieren.
Hier mal ein Screenshot:
www.turbohummel.de/files/2070.png
Übrigens haben Firefox und IE7 ohne zu meckern den Dienst quitiert.
MaxDB, Cloudscape und MySQL haben sich klammheimlich davongeschlichen.
Oracle hat als Datum einfach nur 0 zurückgeliefert.
Beim zurückstellen der Zeit:
- Alle Kekse weg (shit!!!!!)
- Skype und Trillian abgestürzt
- Firewall meinte ich hätte versucht die Lizenz wiederrechtlich zu verlängern
- Winamp spielte Lieder mit doppelter Geschwindigkeit !??!
gepostet vor 18 Jahre, 2 Monate von knalli
Original von Kampfhoernchen
Gedanken machen?
Probieren geht über Studieren.
Hier mal ein Screenshot:
www.turbohummel.de/files/2070.png
Übrigens haben Firefox und IE7 ohne zu meckern den Dienst quitiert.
MaxDB, Cloudscape und MySQL haben sich klammheimlich davongeschlichen.
Oracle hat als Datum einfach nur 0 zurückgeliefert.
Beim zurückstellen der Zeit:
- Alle Kekse weg (shit!!!!!)
- Skype und Trillian abgestürzt
- Firewall meinte ich hätte versucht die Lizenz wiederrechtlich zu verlängern
- Winamp spielte Lieder mit doppelter Geschwindigkeit !??!
Netter Versuch, wenn ich mal lebensmüde bin, werd ich das auch machen und dokumentieren
gepostet vor 18 Jahre, 2 Monate von abuzeus
Original von TheUndeadable
Original von Tetha
Original von TheUndeadable
Daher nutze ich den MySQL-Datentyp DATETIME bzw in C# den nativen Datentyp für Datumsangaben (DateTime)
Hatte Datetime nicht das J10k problem, weil dann die Jahre nicht mehr vierstellig sind?
Ja, das gibt es. Sollte es aber soweit kommen, kann man DateTime einfach erweitern und das Projekt neukompilieren. Mit int als Timestamp ist es nicht möglich, da int auf 32-Bit festgefroren wurde.
Für euch MS-Huren vielleicht ;-)
C++ garantiert folgendes:
sizeof(char) = 1 <= sizeof(short) <= sizeof(int) <= sizeof(long)
außerdem wird garantiert, dass char mindestens 8 bit hat, short mindestens 16 und long mindestens 32. Zusätzlich kann char garantiert ein Zeichen aus dem Zeichensatz des Rechners speichern.
Es spricht übrigens nichts dagegen, dass ein int mit 35 Bit daherkommt und eich char 9 Bit lang ist. C++ ist darauf ausgelegt, mit solchem Unsinn zurechzukommen, man muss halt nur neu kompilieren ;-)
(C++ nimmt nichtmal an, dass dein Quellcode aus Dateien kommt. Keine Ahnung, wo er sonst herkommen sollte, aber offenbar gehts auch anders ;-))
Achja, und: Fliegengewichtmuster
gepostet vor 18 Jahre, 2 Monate von LeoManiac
gepostet vor 18 Jahre, 2 Monate von TheUndeadable
@abuzeus:
Aber auch unter C++ gibt es time_t oder wie auch immer die Struktur heißt.
In einer 'späterer Zeit' kann man time_t 'einfach' auf einen 64-Bit-Integer mappen.
C++ mag es vielleicht garantieren, aber wenn ich mich richtig erinnere haben sich die C++-Compiler-Entwickler darauf geeinigt, dass int 32-bittig bleibt.
> ps: was hat das ganze mit MS zu tun?
Ich werde öfters als MS-Hure dargestellt ;-)
Aber auch unter C++ gibt es time_t oder wie auch immer die Struktur heißt.
In einer 'späterer Zeit' kann man time_t 'einfach' auf einen 64-Bit-Integer mappen.
C++ mag es vielleicht garantieren, aber wenn ich mich richtig erinnere haben sich die C++-Compiler-Entwickler darauf geeinigt, dass int 32-bittig bleibt.
> ps: was hat das ganze mit MS zu tun?
Ich werde öfters als MS-Hure dargestellt ;-)
gepostet vor 18 Jahre, 2 Monate von Itchy
Original von LeoManiac
www.datasource.de/programmierung/tab33_cppdatentypen.html
ps: was hat das ganze mit MS zu tun?
Die Liste ist eine Vorgabe, kein Gesetz.
Wenn Du magst, dann kannst Du Dir Deinen Compiler so konfigurieren, daß ein int 512 Bit breit ist - und Du bleibst trotzdem ANSI C konform. Nur kleiner als die Mindestgrößen (short 16bit, long 32 bit) darf es nicht sein.
gepostet vor 18 Jahre, 2 Monate von LeoManiac
Schon klar aber das sind halt die Default Einstellungen
gepostet vor 18 Jahre, 2 Monate von Kampfhoernchen
An die man sich auch halten sollte.
Ich kann mir ja auch nen neuen Datentyp erfinden ...
Ich kann mir ja auch nen neuen Datentyp erfinden ...
gepostet vor 18 Jahre, 2 Monate von abuzeus
Auch wenn das ganze jetzt etwas abgleitet, aber es sind NICHT die Default-Einstellungen. Die gibt es nämlich nicht. Es sind nur die Werte, die auf der überwiegenden Anzahl der Computer unter der überwiegenden Anzahl der Betriebssystem mit der überwiegenden Anzahl der Compiler benutzt werden. Im Prinzip spricht nichts dagegen, andere Werte zu verwenden. Solange man sich nicht explizit darauf verlässt, dass ein Int nun genau soundsoviel Byte hat sollte vernünftiger Code mit allen Einstellungen laufen (Mindestwerte sind ja garantiert). Man kann natürlich aus Optimierungsgründen festverdrahtete 8 Bit pro Byte nehmen, aber drauf verlassen sollte man sich nicht. Früher war ein Byte btw. nur 6 Bit lang.
time_t ist übrigens nach C-Standard (der "per reference" zum C++-Standard gehört) implementierungsabhängig gestaltet:
Insofern reicht es aus, den time.h entsprechend umzustellen (bzw. nachzusehen, ob er schon umgestellt ist) und dann neu zu kompilieren.
Die MS-Hure war eher ein interner Gag. Sorry ;-)
time_t ist übrigens nach C-Standard (der "per reference" zum C++-Standard gehört) implementierungsabhängig gestaltet:
The range and precision of times representable in clock_t and time_t are implementation-defined.
Insofern reicht es aus, den time.h entsprechend umzustellen (bzw. nachzusehen, ob er schon umgestellt ist) und dann neu zu kompilieren.
Die MS-Hure war eher ein interner Gag. Sorry ;-)