Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » Allgemeines (OffTopic) » unix timestamp, problem nach 2038?

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
13.07.2005, 22:25 Uhr
FloSoft
Medialer Over-Flow
(Administrator)


Hi,
ich frage mich gerade, ob nicht der jahr 2000 "bug" nicht erst am 19. Jan 2038 auftritt, schliesslich gibts dann theoretisch nen speicherüberlauf im unix-timestamp? der ist ja nur ein 32bit integer und wäre dann an seinem maximum?

Was haltet ihr davon, würde mich mal interessieren

ok kann natürlich sein das man bis dahin alles umgestellt hat, aber witzig wärs trotzdem
--
class God : public ChuckNorris { };
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
14.07.2005, 06:40 Uhr
Pler
Einer von Vielen
(Operator)


wäre nicht etwas mehr zeit, wenn das int zb 64 bit hat? Das könnte ja zumind. in neunen Versionen berrücksichtigt werden. Kompatibel müsste es ja ersteinmal bleiben.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
14.07.2005, 08:55 Uhr
virtual
Sexiest Bit alive
(Operator)



Zitat von FloSoft:
Hi,
ich frage mich gerade, ob nicht der jahr 2000 "bug" nicht erst am 19. Jan 2038 auftritt, schliesslich gibts dann theoretisch nen speicherüberlauf im unix-timestamp? der ist ja nur ein 32bit integer und wäre dann an seinem maximum?

Was haltet ihr davon, würde mich mal interessieren

ok kann natürlich sein das man bis dahin alles umgestellt hat, aber witzig wärs trotzdem


Der 2038er Bug ist schon längst da: berechnet man zB das arithemtische Mittel zwischen zwei zeitpunkten, um etwa herauszubekommen, welcher Zeitpunkt zwischen zwei gegebenen zeitpunkten liegt, so findet man häufig die folgende Sequenz:

C++:
time_t start = ...
time_t ende = ...

time_t mitte = (start+ende)/2;


Diese Rechnung funktioniert bereits seit Anfang 2004 nicht mehr, also wenn start und ende Aufzeitpunkte im jahr >=2004 zeigen, so funktioniert da plötzlich was nicht mehr, was früher funktionierte.

Ich denke, man wird die Probleme nach und nach lösen, indem man nach und nach auf 64 Bit portiert; die meisten 64 bit Systeme haben ja einen 32 Bit modus, in dem man nicht portierte Software rennen läßt.

Im günstigsten Fall verschwindet das Problem also einfach durch die anstehenden Portierung auf 64 Bit.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
14.07.2005, 09:39 Uhr
FloSoft
Medialer Over-Flow
(Administrator)


jo das hab ich mir bereits auch schon gedacht, nur 64bit hat schliesslich auch "irgendwo da oben" eine grenze

warum benutzt man nicht jetzt schon (auch auf 32bit systemen) nen 64bit integer für time_t ???
--
class God : public ChuckNorris { };
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
14.07.2005, 10:02 Uhr
virtual
Sexiest Bit alive
(Operator)



Zitat von FloSoft:
jo das hab ich mir bereits auch schon gedacht, nur 64bit hat schliesslich auch "irgendwo da oben" eine grenze

Tja, sicher. Aber hast Du mal ausgerechnet, wann die erreicht wird? - die 31 Bit (ein Bit ist ja vorzeichen) reichen ja für 68 Jahre. Dh 63 Bit rechen Pi mal daumen für 68*4 Milliarden jahre... Vermutlich werden die Rechner bis dahin noch die einen oder anderen Bits dazu bekommen


Zitat von FloSoft:
warum benutzt man nicht jetzt schon (auch auf 32bit systemen) nen 64bit integer für time_t ???


Ich glaube, das würde nicht wirklich helfen... Also ich glaube das Problem liegt eher an den Daten: ist ja ganz toll, wenn ich ein 64 Bittiges Programm habe, aber was mache ich mit den daten, welche auf 32 Bit basis erstellt wurde. Ich halte Datenmigration für ein mindest ebenso großes problem wie die migrations des Programmcodes.

Und es gibt eben eine ganze Reihe von 32 Bit Problemen: nehmen wir als einfaches Beispiel mal die Dateigrößen: die arbeiten auf vielen System mit der heutzutage lächerlichen Beschränkung, daß eine einzelene Datei grade mal 2 GB groß sein darf. Wäre also auch ein Kandidat für 64 Bit. Und so findet man einige Beispiele. Mir ist da ein konsequenter Rundumschlag lieber, der dann alles auf 64 Bit bringt und das macht wohl eher sinn, wenn die hardware auch da ist. Denn sonst könnte man ja jetzt schon mit der Portierung von 256 Bit Systemen beginnen, weil die vielleicht in 20 Jahren auf den markt kommen.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ Allgemeines (OffTopic) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: