Tisdagen den 19 Januari 2038 inträffar en alvarligare bugg än y2k-problemet. Då tar nämligen tidsstämplarna, som representerar sekunder i datorerna, helt enkelt slut. Allt som sker i datorerna tidsstämplas, alla händelser. Datorerna behöver tidsstämplarna för att kunna ordna upp de olika händelserna och fungera.

När klockan i datorerna räknar en sekund över 2038 så kommer allt slå om – och systemet tror plötsligt det är fredagen den 13 december 1901 - Lucia, men 137 år fel.

2038-buggen beror på att många datorers operativsystems tidsstämplar räknar sekunder i ett 32-bitar system och har gjort så sedan 1970. Det har tickat och gått sedan dess. Men det ryms bara ett begränsat antal tidsstämplar i ett 32-bitar system. Ungefär drygt 2 miljarder sekunder. Så antalet sekunder som klockan kan räkna kommer att ta slut.

Främst kommer datorer med Unix-liknande operativsystem att drabbas, det kan bli problem anläggningar och system med längre livslängd, som kärnkraftverk, flygplan och banksystem. Lösningen är att byta ut 32-bitar systemet mot 64-bitar, då har vi sekunder eller tidsstämplar som räcker längre än vad universum beräknas finnas kvar.

läste dagens icke nyhet på aftonhoran också.

Undrar va dom får 13 dec 1901 ifrån bara.

den börjar nämligen räkna ifrån
12 / 31 / 69 @ 6:00:01pm

Skönt att jag redan upgraderat till 64 bit i tid, så man inte behöver oroa sig =)

Min, liksom de flesta PC börjar räkna från 1980. Sun-datorer och silicon graphics börjar räkna från 1970, så jag undrar vad du sitter på för hårdvara apan

Hm, borde inte i princip alla datorer var minst 64-bit år 2038? Är det ett problem eg?

Problemet är väl först när det gäller datorer i flygplan exempelvis... De datorer vi sitter och knappar på borde nästan vara 256-bitars 2038, så det är ju ingen större fara... Men de som har datorer embedded är det ju lite annorlunda med.

maskinparken uppgaderas alltid....

Inte i bilar, flygplan etc... Tänk också alla industrirobotar med integrerade datorer.

Det rör en hel del saker, med det är också många år kvar...

det blev lite fel när den börjar räkna pga tidszon.
date -d @1
Thu Jan 1 07:00:01 ICT 1970
date -d "20091229" +%s
1262019600
date -d @1262019600
Tue Dec 29 00:00:00 ICT 2009

All *nix system använder det här sättet att räkna tid.
2 upphöjt till 32 -1 är max antal sekunder för att det motsvarar ett 32 bitars heltal som bara kan ha positiva värden.

på ett 32 bitars system så funkar det inte med ett större tal än så.
date -d @12620196001 funkar intepå 32 bitars men 64 bitars blir det
Tue Dec 2 02:00:01 UTC 2369

Quote:

Jag skulle vilja se den programmeraren som gjorde fulkoden som krashar på grund av den tid som systemklockan har.

Ett flygplan borde exempelvis inte bry sig om att det är den 10 december när den flyger fram genom luften, den borde exempelvis endast kolla höjd och riktning (som är relevant för uppgiften.)

Det är ungefär som att titta på klockan när man ska ta ett viktigt politiskt beslut angående år 3000, irrelevant!

Fast de flesta datorer jobbar ju med ticks. Dvs tid som rymmer mellan uträkningarna.

Då kan den väl börja på "noll" ticks + lagra ett datum och nollställa ticksen varje gång som den räknar upp datumet... (den behöver bara göra detta var ~50:e år...)

(Satt en gång i tiden och programmerade en j*vla almenacka i ADA i ett unixsystem, datumtiden fungerade oavsett vad man ställde in för tid på systemklockan, klarade tillockmed av överslaget från maxdatumet till mindatumet systemet utförde utan att visa fel datum, tack vare lite intelligent programmering)

Äsch! Ni fattar ju inte... Visst att detta inte är ett hot eftersom vi har gott om tid på oss... Men skulle detta vara exempelvis nu 2010 så skulle det kokta fläsket vara stekt... Även om vi inte räknade med vanliga datorer.

http://en.wikipedia.org/wiki/Year_2038_problem
http://sv.wikipedia.org/wiki/%C3%85r_2038-problemet