| von cmuecke |
M$ hatte früher auch Probleme mit langen Integern. In Windows 95 und 98 hatte die Datei "VTDAPI.VXD" eine Begrenzung von 2 hoch 32 Millisekunden (etwa 4.294.967.296 ms). Wenn die Zahl erreicht wurde, stürzt(e) der Computer ab.
Erst nach zwei (!) Jahren wurde dran gewerkelt, obwohl das Problem schon lange bekannt war.
Ich glaube, bis 2038 werden wohl schlaue Köpfe sich eine Lösung einfallen lassen...
mfg,
Christian
---
http://sylver-web.de
Weisheiten:
- Das Wesen der Dinge hat die Angewohnheit, sich zu verbergen. - Heraklit (griech. Philosoph)
- Wären alle Menschen gleich, würde im Prinzip einer genügen. (unbekannt) |
| von Helmut_maieR |
was wird dann passieren...
einfach gesagt NIX!
in einigen jahren haben wir warscheinlich genügen große ints und longs.
also keine sorgen vor dem 2038bug 
---
... Chaos muß sein, woraus sollte man sonst Ordnung machen? ... |
| von Elliot |
Surviving Year 2038?
We just lived through the millennium problem, which - fortunately -- was a big yawner. In a few years, prepare to face another Unix-specific time problem -- Year 2038.
The number of seconds since the epoch is stored in a long integer data type having the capacity of 2147483647 (defined as constant LONG_MAX located in /usr/include/limits.h). 2,147,483,647 seconds from the epoch, on Jan 19 03:14:07 2038 CVT, a long int overflows and present Unix systems have a very bad day.
http://www.unixreview.com/documents/s=1236/urm0104k/0104k.htm
---
Elliot - Das Schmunzelmonster |
| von michael |
Durch einen Zufall bin ich gerade auf folgendes Datum gestoßen: 19.01.2038 - das ist der letzte Tag an dem ich die Timestamp korrekt verarbeiten kann (z.B. beim umwandeln in einen Wochentag) - ab 20.01.2038 geht das nicht mehr...
was bitte passiert an diesem tag und auf welcher logik basiert es? an dem tag bekommt die timestamp ja keine weitere stelle oder ähnliches...
oder hat man damals 1970 entschieden, dass die welt 2038 untergeht?
|
|
