In 2000 verliep de millenniumbug zonder veel problemen. Ondanks voorspellingen van een grootschalig falen werd een crisis afgewend door zowel langetermijn- als last-minute-planning en ingrijpen, en zijn er geen kritieke systemen uitgevallen. In de jaren daarna zijn de weinige getroffen besturingssystemen en toepassingen in de meeste gevallen bijgewerkt, vervangen of buiten gebruik gesteld.
Als u een Unix- of Linux-gebaseerd systeem gebruikt, is er nog een datumgerelateerde bug waar u zich zorgen over moet maken — in het jaar 2038.
Alle 32-bit Unix/Linux-gebaseerde systemen slaan de systeemkloktijd intern op als het aantal seconden sinds de Epoch, of 00:00:00 op 1 januari 1970. Dit interne gegevenstype, time_t, is in de meeste gevallen een 32-bits (4 bytes) integer met voorteken. Als het systeem in kwestie de POSIX-standaard volgt (zoals de meeste Unix- en Linux-systemen doen), is de laatste tijd en datum die kan worden weergegeven als seconden-vanaf-de-epositie in dat 32-bits ondertekende gehele getal 3:14:07 UTC op dinsdag 19 januari 2038.
Na deze tijd en datum zal de interne weergave van de systeemtijd 2147483647 bereiken, het hoogste getal dat kan worden opgeslagen in een 32-bits ondertekend geheel getal. Een seconde daarna zal het omslaan naar een negatief getal, -2147483648. Huidige toepassingen zullen dit negatieve getal interpreteren als een ouder jaar (1901) of de systeemklok bevriezen op 03:14:07 op 1/19/2038. Dit kan tot gevolg hebben dat toepassingen en besturingssystemen falen, omdat ze niet zijn ontworpen om te werken met een vastgelopen systeemklok of een klok die het jaartal 1901 aangeeft.
Er zijn geen werkbare oplossingen (die bestaande toepassingen niet kapot maken) voor systemen die 32-bit processoren gebruiken, of besturingssystemen en toepassingen die in 32-bit modus op 64-bit processoren draaien. Veel huidige Unix/Linux-besturingssystemen draaien al in 64-bits modus (met een bijbehorende “lange” time_t wanneer op een 64-bits processor; in de meeste gevallen lost dit het probleem op.
Besturingssystemen die een lange 64-bits time_t ondersteunen, worden hoogstwaarschijnlijk niet beïnvloed door de Year 2038-bug in termen van de interne systeemklok. Toepassingen die een 32-bits time_t gebruiken, kunnen echter nog steeds falen, zelfs als het systeem waarop de toepassing draait volledige 64-bits werking ondersteunt.
Hier is een kort overzicht van de huidige status van de Unix 2038-ondersteuning in mainstream Unix/Linux-releases:
- Solaris 7 of hoger op 64-bits UltraSPARC- en SPARC64-processors, evenals Solaris 10 op x86-64-platforms, heeft een 64-bits time_t.
- AIX versie 4.3.3 op 64-bit PowerPC en Power processoren heeft een 64-bit time_t.
- De Linux kernel die in 64-bit mode draait op IA64 of x86-64 processoren heeft een 64-bit time_t.
- Mac OS X Version 10.4 en nieuwer heeft een 32-bits kernel, maar toepassingen kunnen een 64-bits time_t gebruiken wanneer deze op PowerPC G5- of x86-64 CPU’s draait.
- FreeBSD 6.0 en hoger heeft een 64-bits time_t wanneer deze op een 64-bits platform draait.
- OpenBSD 4.1 en nieuwer ondersteunen een 64-bit time_t.
- NetBSD heeft nog geen 64-bit time_t, maar er wordt aan gewerkt om het probleem te verhelpen voor een komende release.
Zelfs als uw huidige besturingssysteem nog niet Unix 2038-veilig is, hoeft u zich geen zorgen te maken! Men is zich al vele jaren bewust van het probleem, en werkt actief aan oplossingen. In de meeste gevallen zal het probleem worden opgelost door het besturingssysteem en de toepassingen uiteindelijk in volledige 64-bit modus te laten draaien.
Ik verwacht dat alle belangrijke desktop-besturingssystemen in de komende vijf tot tien jaar volledig 64-bit zullen zijn. Bovendien zal een trickle down effect helpen om huidige systemen te vervangen door 64-bit configuraties waar het toepasbaar en kosteneffectief is.
OVER DE AUTEUR: Bill Bradford is de bedenker en beheerder van SunHELP en woont in Houston, Texas, met zijn vrouw Amy.