Tien jaar milleniumbug

Met de jaarwisseling zijn er altijd mensen die niet kunnen meevieren met hun familie omdat ze moeten werken. Denk aan brandweermannen, mensen uit de zorg en ga zo maar door. Maar tijdens de overgang van 1999 naar 2000 kwam daar nog een andere groep mensen bij: de informatici. En wie of wat was daar verantwoordelijk voor? De millenniumbug, in het land van nulletjes en eentjes ook wel bekend als de Y2K-bug. De bug veroorzaakte heel wat onrust, zowel bij bedrijven als consumenten. Tien jaar later is het duidelijk dat we allemaal nog leven, maar wat is er tien jaar geleden precies gebeurd en welke gevolgen heeft dat gehad? Daar willen we in deze blog iets verder op ingaan.

Oorzaak van de bug

Om geheugen te sparen hadden programmeurs de datums in hun programma opgeslaan in zes cijfers: twee voor de dag, twee voor de maand en twee voor het jaar. Het probleem zat hem in die laatste twee cijfers. Bij de overgang van 31 december 1999 naar 1 januari 2000 zou de computer ervan uitgaan dat we terug in het jaar 1900 beland zijn. Vooral bij applicaties die moeten werken met datums, kan dat de werking van het programma ernstig verstoren. Het probleem werd voor het eerst aangekaart in het boek "Computer in Crisis", dat gepubliceerd werd in 1984.

Oplossingen voor de bug

Voor het oplossen van de bug zijn er verschillende oplossingen, maar twee ervan werden het meest gebruikt: date expansion en windowing. De eerste oplossing is naast de eenvoudigste ook de meest correcte. Bij date expansion worden twee extra cijfers aan de datum toegevoegd. Op die manier wordt het jaartal opnieuw voorgesteld door vier cijfers, waardoor de overgang van 1999 naar 2000 verloopt zoals het zou moeten. Voordeel van deze methode is dat ze definitief is en geen enkel onderhoudswerk vraagt. Nadeel is dat de methode vereist dat de hele broncode van een programma nagelopen wordt, wat deze methode de meest tijdsintensieve en dus ook duurste maakt.

Windowing is eerder een lapmiddeltje dan een echte oplossing. Bij deze methode wordt aan de applicatie opgelegd binnen welke honderd jaar gerekend moet worden. Stel je bijvoorbeeld in dat de applicatie van 1980 tot 2080 loopt, dan kan er geen verwarring over de datum 01-01-00 ontstaan, dat is ontegensprekelijk 1 januari 2000. Het voordeel is dat dit makkelijk en dus goedkoop te implementeren valt, het nadeel is dat dit geen oplossing is voor applicaties die moeten werken met datums uit het verre verleden. Hoewel dit geen definitieve oplossing lijkt, volstond ze in de meeste gevallen. Tenslotte gingen de applicatiemakers er -terecht- van uit dat de datum in de nieuwe versie van de software wel meteen correct werd geprogrammeerd.

Hoe de Y2K-bug India op de kaart zette

In de tien jaar voor de bewuste jaarwisseling had zich van alles afgespeeld in de snelgegroeide IT-sector. Eén van die dingen was een gigantische overinvestering in het glasvezelnetwerk dat computernetwerken over heel de wereld met elkaar verbond. Later zou echter blijken dat die overinvestering samen met de Y2K-bug een godsgeschenk was voor India. Om al die broncode op relatief korte duur te herschrijven, was namelijk een gigantisch aantal programmeurs nodig. Een aantal dat simpelweg niet voorhanden was in de westerse wereld. Bovendien was het werk saai en zou het inzetten van hoogopgeleide en –betaalde programmeurs voor deze taak een gigantische kost betekenen voor bedrijven.

Maar door de overinvestering in glasvezel was de verbinding relatief goedkoop om te gebruiken. Dat betekende dat er een snelle en goedkope verbinding was tussen India en de westerse wereld en dus werden miljoenen computers Y2K-proof gemaakt vanuit India. Dat betekende een enorme groei voor de Indische IT-branche en bovendien was een nieuw, belangrijk economisch principe ontstaan, dat van outsourcing. Daarbij wordt werk voor een bedrijf verricht op een compleet andere locatie dan waar het bedrijf zich bevindt. En dat is meteen ook de reden waarom het bij het bellen van de helpdesk van een groot bedrijf niet onmogelijk is dat de man aan de andere kant van de lijn zich in India bevindt

Massahysterie en anticlimax

De bug veroorzaakte heel wat onrust, vaak omdat mensen niet wisten wat de milleniumbug precies was en op welke aspecten van het dagelijkse leven de bug een invloed zou hebben. De meest extreme verhalen deden de ronde: vliegtuigen konden zomaar uit de lucht vallen, bankautomaten werden enorm vrijgevig of blokkeerden en zelfs je auto zou niet veilig zijn geweest voor de millenniumbug. Vooral in Amerika werd dat commercieel uitgebuit, daar werden zelfs Y2K-compatibele startkabels verkocht.

Op 1 januari 2000 bleek dat allemaal best mee te vallen. Vliegtuigen bleven gewoon in de lucht en bankautomaten spuwden nog steeds het juiste bedrag uit. Kortom, niks aan het handje. De hele hetze rond de millenniumbug was dus een maat voor niets? Ja en nee. Ja, in die zin dat de gevolgen van de millenniumbug zwaar overroepen waren en alle grote instanties goed voorbereid waren, in tegenstelling tot wat de algemene opinie dacht. Het blijft wel een feit dat de eerdergenoemde Indische programmeurs de westerse wereld een enorme dienst hebben bewezen. Zonder hun hulp was het aanpassen van al die miljoenen regels code een veel grotere en duurdere klus geweest. Bovendien is de kans groot dat de klus niet was afgeraakt, wat ervoor had gezorgd dat we de gevolgen van de Y2K-bug ongetwijfeld beter hadden gevoeld.

More, please…

Maar de Y2K-bug is niet de enige term die de woorden datum, probleem en computer in één zin zet. Zo is er ook nog de Year 2038-bug. Unix slaat tijdswaarden namelijk op als seconden sinds 1 januari 1970, middernacht (de zogenaamde ‘Unix Epoch’). Dat getal wordt opgeslaan in een binair getal, bestaande uit 32 bits. Op 19 januari 2038 ziet dat getal er echter uit als een 1, gevolgd door 31 nullen. De eerste 1 van die 32 bits maakt het getal echter negatief, waardoor de applicatie de tijd zal interpreteren als 1970 of 1901, afhankelijk van de manier waarop ze werd geprogrammeerd. Hoewel 2038 behoorlijk veraf lijkt, kan het probleem nu al problemen opleveren met applicaties die dertig jaar verder in de toekomst kijken. Om deze bug op te lossen kan overgestapt worden naar 64-bit integers, wat ervoor zorgt dat het probleem pas opnieuw kan optreden op 4 december 292.277.026.596. Meteen ook de datum van een nieuwe blogpost over dit item. Tot dan!