Året 2000 kom och gick Y2K-buggen utan större problem. Trots förutsägelser om ett utbrett misslyckande avvärjdes krisen genom både långsiktig planering och ingripanden i sista minuten, och inga kritiska system gick sönder. Under de år som gått sedan dess har de få operativsystem och program som påverkades i de flesta fall uppgraderats, bytts ut eller dragits tillbaka.
Om du använder ett Unix- eller Linuxbaserat system finns det ytterligare en datarelaterad bugg som du behöver oroa dig för – år 2038.
Alla 32-bitars Unix/Linux-baserade system lagrar systemklockans tid internt som antalet sekunder sedan epok, eller 00:00:00 den 1 januari 1970. Denna interna datatyp, time_t, är i de flesta fall ett 32-bitars (4 byte) signerat heltal. Om systemet i fråga följer POSIX-standarden (vilket de flesta Unix- och Linuxsystem gör) är den senaste tiden och det senaste datumet som kan representeras som sekunder sedan epoken i det 32-bitars signerade heltalet 3:14:07 UTC tisdagen den 19 januari 2038.
Efter denna tid och detta datum kommer den interna representationen av systemtiden att nå 2147483647, det högsta talet som kan lagras i ett 32-bitars signerat heltal. En sekund efter det kommer den att gå runt till ett negativt tal, -214748363648. Nuvarande program kommer antingen att tolka detta negativa tal som ett äldre år (1901) eller frysa systemklockan till 03:14:07 den 19/1/2038. Detta kan leda till att program och operativsystem misslyckas, eftersom de inte är konstruerade för att fungera med en hängande systemklocka eller en klocka som visar år 1901.
Det finns inga fungerande lösningar (som inte bryter ner befintliga program) för system som använder 32-bitars processorer, eller för operativsystem och program som körs i 32-bitarsläge på 64-bitars processorer. Många nuvarande Unix/Linux-operativsystem körs redan i 64-bitarsläge (med en motsvarande ”lång” time_t) på en 64-bitars processor; i de flesta fall löser detta problemet.
Operativsystem som har stöd för en lång 64-bitars time_t påverkas sannolikt inte av felet Year 2038 när det gäller den interna systemklockan. Program som använder en 32-bitars time_t kan dock fortfarande misslyckas, även om systemet som kör programmet har stöd för full 64-bitars drift.
Här är en snabb översikt över den nuvarande statusen för Unix 2038-stödet i vanliga Unix/Linux-versioner:
- Solaris 7 eller högre på 64-bitars UltraSPARC- och SPARC64-processorer, samt Solaris 10 på x86-64-plattformar, har en 64-bitars time_t.
- AIX version 4.3.3 på 64-bitars PowerPC- och Power-processorer har en 64-bitars time_t.
- Linuxkärnan som körs i 64-bitarsläge på IA64- eller x86-64-processorer har en 64-bitars time_t.
- Mac OS X version 10.4 och nyare har en 32-bitars kärna, men program kan använda en 64-bitars time_t när de körs på PowerPC G5- eller x86-64-processorer.
- FreeBSD 6.0 och senare har en 64-bitars time_t när de körs på en 64-bitars plattform.
- OpenBSD 4.1 och nyare har stöd för en 64-bitars time_t.
- NetBSD har ännu inte en 64-bitars time_t, men ansträngningar pågår för att åtgärda problemet till en kommande utgåva.
Även om ditt nuvarande operativsystem ännu inte är Unix 2038-säkert behöver du inte oroa dig! Folk har varit medvetna om problemet i många år nu och arbetar aktivt på lösningar. I de flesta fall kommer problemet att lösas genom att operativsystemet och programmen så småningom körs i fullt 64-bitarsläge.
Jag förväntar mig att alla större operativsystem för stationära datorer kommer att vara fullt 64-bitars inom de närmaste fem till tio åren. Dessutom kommer en trickle down-effekt att bidra till att ersätta nuvarande system med 64-bitskonfigurationer där det är tillämpligt och kostnadseffektivt.
Om författaren: Bill Bradford är skapare och underhållare av SunHELP och bor i Houston, Texas, med sin fru Amy.