Unixtime - Y2k037: Hva skjer da?

[pgdx]

Jobbes det med problemet? I år 2037 er det ikke mer tid igjen. Hva skjer da? Går universet under? Hva er da vitsen?

 

Venter vi til året før med å løse problemet som sist gang? Håper det går bra en gang til?

 

~~~~

 

Emnetittel redigert. "Unixtime - Y2k037" er et brudd på tre-ords-regelen. PoleCat

Endret 31. januar 2005 av PoleCat

[kyrsjo]

Er ikke problemet en eller annen teller som slipper opp for tall? Hvor mange bits er denne telleren på i dag? Hvor mange bits er dagens datamaskiner på?

 

Hvor stor forsjkell er det i datamaskiner anno 1965 og 2005?

 

Enkleste er vel rett og slett å begynne å tilby det som en mulighet i kjerneconfig - en 10-5 år i forveien. Akkurat nå tror jeg ingen *egentlig* bryr seg... Spesiellt ikke hvis en "lengre datatype" medfører en minste ytelsesreduksjon.

[kattemat]

Problemet er jo ikke akkurat for desktopsystemer, men for produksjonsservere som står og putrer og går i åresvis. Løsningen for systemer som kan oppdateres er vel å gå over til 64 bits definisjon av time_t. Les mer på:

http://www.deepsky.com/~merovech/2038.html

[JBlack]

64 bit blir bra. Da har vi klokke frem til ca. år 292.471.211.000 (avrundet til nærmeste årtusen)

[genstian]

64-bit "blir" ikke bra.

64-bit "er" bra

[JBlack]

64-bit "blir" ikke bra.

64-bit "er" bra

#include <stdio.h>
#include <time.h>

int main(){
       printf("%i\n",sizeof(time_t));

}

 

$ uname -p
AMD Athlon(tm) 64 Processor 3000+
$ gcc time_t.c -o time_t
$ ./time_t
8

[pgdx]

64 bit blir bra. Da har vi klokke frem til ca. år 292.471.211.000 (avrundet til nærmeste årtusen)

Okey... Ja, men det skulle jo så vidt holde.

 

Men jobbes det ikke med det til f.eks Linux-kjernen i dag?