Millenniebuggen

Millenniebuggen, År 2000-problemet eller Y2K-problemet, var en brist i utformningen av datorprogram och system som innebar att dessa inte skulle komma att fungera för datum efter 31 december 1999. Akronymen Y2K är av engelskspråkigt ursprung och bildat av Y, för Year, år, och 2K för 2 kilo = 2000. Termen "Y2K" myntades 1995 i ett e-postmeddelande sänt av en programmerare från Massachusetts vid namn David Eddy. 

Millenniebuggen orsakade stor uppståndelse och mycket bekymmer i slutet av 1990-talet när sekelskiftet närmade sig, och stora summor pengar (flera miljarder) spenderades av företag, organisationer och myndigheter över hela världen för att åtgärda problemet och korrigera programmen. Problemet fick också stor uppmärksamhet i massmedia, blev föremål för mycket spekulationer och fick många att frukta att vitala datasystem och samhällsfunktioner skulle bryta samman vid nyåret år 2000. När sedan dessa farhågor inte besannades, uppfattades detta av många som att problemet egentligen inte hade existerat utan hade förstorats upp till orimliga proportioner i egensyfte av IT-branschen. Det har också gjort att Millenniebuggen i vissa sammanhang kommit att beteckna just den överdrivna oro som uppstod inför millennieskiftet 1999–2000.

Det bakomliggande felet 
Den påpekade bristen i datasystemen var högst verklig. I de flesta (även helt moderna) datasystem lagras uppgifter på ett sätt som gör att man i förväg måste bestämma sig för hur stort utrymme i datorns minne eller i databasernas poster en viss typ av information ska ta. En sifferuppgift kan därför oftast bara innehålla ett begränsat antal siffror och en bit text kan bara högst bestå av ett visst antal tecken, om man inte enkom använder mer komplicerade datastrukturer.

De flesta datasystem hanterar årtal på ett sätt som inte inkluderade alla siffrorna i det fullständiga årtalet: 1989 kan, väldigt förenklat, lagras som "89" och 1942 som "42". Så länge man adderar 1900 till året fungerar aritmetik och jämförelser på sådana tvåsiffriga tal med fyrsiffriga tal alldeles utmärkt. Att få fram nästa eller föregående år utgående från ett givet värde kräver endast en enkel addition eller subtraktion, och att avgöra om ett år var tidigare eller senare än ett annat kräver endast en enkel jämförelse av talens värden.

Allt detta ger emellertid problem om systemet inte kan lagra värden över 99, som sker om värdet lagras som text istället för binärt, eller om programmeraren inte hade adderat startåret, 1900, och programmet skulle arbeta med årtal utanför 1900-talet.

Årtalet 1900, som i normalfallet representerades med talet "0", var ofta det tidigaste möjliga årtalet i systemen, medan år 2000 och senare blir år "100" och uppåt, eller i värsta fall inte alls kan representeras eller blir till ett negativt tal.

Om man utgående från årtalet "97" vill beräkna årtalet fyra år framåt och lagrar informationen i två tecken får man 97+4=101, vilket i många fall blir "01" när det ska klämmas in på två positioner. Beroende på programspråk, typ av dator med mera kan det då antingen orsaka att programmet avbryts och systemet stannar, eller också går händelsen spårlöst förbi med ett resultat som ligger 96 år bakåt i tiden istället för 4 år framåt. Båda konsekvenserna kan på sikt vara lika ödesdigra för systemets funktion. Detta problem uppstår bara i det läge då systemet lagrar informationen som text (två tecken) eller binärkodade decimaltal (två siffror), inte som rena binära tal, då talen hundra och tvåtusen inte på något sätt är speciella som binära tal.

Även om hundratalssiffran rent beräkningsmässigt inte skulle tappas bort skulle värdet 101, 19101 eller liknande istället för 2001 inte vara acceptabelt då det visas för en människa.

De system som lagrar binärt får också problem med att värdet "slår runt" och hamnar på negativa värden, eller "0" igen, då utrymmet fortfarande är begränsat för att lagra siffror eller tal och förr eller senare tar utrymmet slut. När värdet slår runt beror på vald nollpunkt, tidsenhet och hur stora tal man valt att kunna representera.

Ett speciellt problem var integrerade kretsar i inbyggda system. Exakt vilka komponenter man använt är sällan väldokumenterat och man var rädd att kretsar som innehöll en klockfunktion, oberoende av om funktionen används, kunde sluta fungera då klockan slår runt. Ifall binärkodade decimaltal används kunde detta hända kring år 2000 (beroende på hur väl klockan gick rätt).

De flesta datasystem använder binära tal för att representera tiden, varvid nyårsskiftet 1999–2000 inte är speciellt: utrymmet tar inte slut då utan senare. Det finns dock viktiga undantag. Till exempel datorprogram skrivna i COBOL utnyttjade ofta binärkodade decimaltal. Likaså lagrades tiden på PC-datorers moderkort i denna form.

De flesta datasystem bearbetar också datum i ett visst intervall, både framåt och bakåt i tiden. Felet började därför dyka upp långt innan millennieskiftet, och kan fortfarande orsaka problem så länge det finns program som inte korrigerats och som behandlar årtal utanför det intervall programmen är gjorda för. En tidpunkt som berör många datasystem infaller 2038, då POSIX-tiden inte mera ryms i 32 bitar (år 2038-problemet).

Bakgrund 
I datorernas barndom var minne och lagringsutrymme en bristvara, och man undvek att lagra mer data än vad som var nödvändigt. De olika media som användes för att mata in och presentera data på 1970- och 80-talen hade också rent fysiska begränsningar som gjorde att datauppgift måste ges en fast position och begränsad längd, exempelvis på ett hålkort, en textbaserad bildskärm eller i en pappersutskrift. 

Många av de programspråk som användes på den tiden, exempelvis COBOL, erbjöd inte heller några sofistikerade funktioner för att redigera och formatera data och det var därför naturligt att lagra ett datum ungefär på samma sätt som det normalt matades in i eller skrevs ut från systemet – som ett tvåsiffrigt tal, vilket i vardagslag var det normala sättet att ange årtal även utanför datorernas värd. 
 
De flesta tids- och datumuppgifter i ett specifikt datasystem rör sig inom ett ganska snävt intervall och det var därför sällan ett problem att det inte samtidigt gick att hantera 1889, 1989 och 2089 i systemet – det var oftast självklart att det var 1989 som avsågs med värdet "89". De flesta system hade (och har) också en ganska kort livslängd och det var relativt få programmerare som på 80-talet bekymrade sig för om deras system skulle fungera ett decennium senare.

En av de första som uppmärksammade problemet med att använda för få siffror i årtal var datavetaren Bob Bemer från IBM som redan 1958 lär ha noterat problemet i samband med arbete med programvara som behandlade genealogiska data. I början av 1970-talet skrev han flera artiklar där han offentligt varnade för konsekvenserna och uppmanade programmerare att öka längden till fyra siffror. Han fortsatte de efterföljande decennierna att försöka få IBM, olika myndigheter och ISO att ta sig an problemet, men utan något påtagligt resultat.

Allt eftersom det nya seklet kom närmare började fel dyka upp i system som hanterade årtal efter 2000, exempelvis kunde låntagare i början av 1990-talet med lån som sträckte sig in på det nya seklet få anmärkningar på att de låg över 90 år efter med amorteringarna. Det var dock egentligen först runt mitten på decenniet som programmerare började ta problemet på allvar i någon större omfattning. Företag och myndigheter började inventera sina system och kom fram till att en stor del av dem krävde omfattande förändringar för att klara övergången till det nya seklet, och arbete med detta startades i allmänhet också upp.

Många av de berörda systemen var gamla och hade körts i åratal utan större modifieringar. I vissa fall saknades tillräcklig dokumentation och kunskap om systemen och det var istället enklare att ersätta dem med nya system. Inte bara enskilda system visade sig behöva förändras. Relativt tidigt började leverantörer av operativsystem, databashanterare och hårdvara att se över sina produkter och parallellt med att deras kunder arbetade med sina egna system började de själva producera nya "Y2K-säkra" versioner och modeller av sina produkter. Det vanligaste operativsystemet, DOS, och nästan alla hem- och företagsdatorer klarade sig dock utan förändringar av hårdvaran för att klara övergången; redan de allra första versionerna av DOS, från början av 80-talet, klarar årtal efter 2000, förutsatt att till exempel "10" tolkas som 2010.

De sista åren på 1990-talet 
Allt eftersom sekelskiftet närmade sig blev fokus på Y2K-problemet allt större. När insatserna för att korrigera systemen började öka, innebar det ofta i praktiken att resurser som tidigare varit inriktade mot att skapa nya system fick ägna sig åt att bygga om gamla system istället. Ju senare man startade desto intensivare blev korrigeringsarbetet och desto mer resurser krävdes för att klara av det. Under denna tid granskades miljarder rader programkod och miljontals rader rättades.

Det är svårt att ge exakta uppgifter, men det har beräknats att amerikanska myndigheter spenderade 9 miljarder dollar, och att det i USA lades ned över 100 miljarder dollar på att förebygga och rätta Y2K-relaterade fel.

När arbetet med att korrigera systemen började sysselsätta en allt större del av IT-branschen, började det också uppmärksammas i medierna och av allmänheten. Anekdoter om inträffade och befarade problem började florera. Under 1999 blev Y2K-problemet en betydande mediehändelse, och farhågorna och spekulationerna fick stundtals ofantliga proportioner.

Problemets egentliga natur missförstods i allmänhet, och det uppstod ett felaktigt fokus på just nyårsafton och övergången till det nya seklet. Man befarade att viktiga delar av samhällets funktioner skulle kunna slås ut 1 januari 2000 genom att system inom bankväsendet, energiförsörjningen och transportväsendet då skulle sluta att fungera. Man spekulerade att hissar skulle stanna, flygplan skulle haverera och mycket annat. 

Det spekulerades att vissa länder, som exempelvis Ryssland, inte skulle ha resurser att åtgärda alla fel och att följderna där därför skulle bli katastrofala. Religiöst färgade domedagsprofetior förekom också.

Försäkringsbolag sålde försäkringar som skulle täcka eventuella förluster för företagen på grund av Y2K-problem. På vissa håll i världen hamstrade människor mat och pengar för att kunna klara sig om profetiorna besannades.

Nyåret 1999–2000 

Många företag och myndigheter upprättade kris- och beredskapsorganisationer runt årsskiftet och gjorde sig beredda på det värsta, men årsskiftet kom och gick utan några större incidenter.

I media talades det om antiklimax och många människor reagerade med upprördhet över att så mycket pengar och arbete hade slösats bort i onödan på något som tydligen inte var något större problem. Man framkastade tanken att det kanske hade varit bättre att inte göra något i förväg utan istället ta hand om de fel som faktiskt skulle ha inträffat, istället för att spendera miljarder på att i förväg leta efter fel i systemen. För alla de människor som deltagit i detta arbete var resultatet istället en bekräftelse på att insatserna faktiskt hade gjort nytta.

Exempel på fel som har inträffat 
 Ett kärnkraftverk i Japan fick stoppas tillfälligt i början av januari 2000 då ett hjälpsystem krånglade.  
 Data från amerikanska spionsatelliter kunde inte bearbetas under en tid i samband med årsskiftet. Även franska militärsatelliter drabbades.
 Den brittiska varuhuskedjan Marks and Spencers lagerhanteringssystem föreslog att ett parti köttkonserver skulle kasseras, då burkarnas bäst-före-datum, "02", tolkades som 1902.
 Felaktiga testresultat om Downs syndrom skickades ut till 154 gravida kvinnor i England. Två kvinnor gjorde abort och fyra barn med Downs syndrom föddes av kvinnor som fått felaktigt besked att de var i lågriskgruppen.
 En del datumangivelser på olika håll i världen visade år 1900 alternativt 19100 istället för 2000.

Referenser

Noter

Allmänna källor 
 DeJesus, Edmund X. (1998). "Year 2000 Survival Guide". BYTE, Juli 1998, vol. 23, nr. 7 (det sista numret av BYTE). 
 Keogh, Jim (1998). "Working to Solve the Year 2000 Problem". Kap. 12 (pp. 307–329) av COBOL Programmer's Notebook. Upper Saddle River, NJ: Prentice-Hall PTR. .

Externa länkar

Allmänt 
 The Surprising Legacy Of Y2K – Radiodokumentär av American Public Media 1995, om historien bakom den kommande "millenniumbuggen".
 Battling the bug - www.PopSci.com | Y2K Citat: "...Detta är status för vissa nyckelindustrier för närvarande..."
 BBC News: Millennium Bug, Around the world
 BBC News: Millennium Bug, Bugtown UK
 Y2K – Microsoft Windows 98 är INTE anpassad, säger fransk minister 27-2-99

Kritiska kommentarer 
 "A New Year's Embarassment for Y2K doomsters" – av Wynn Quon, Mitel Corp. (publicerad i National Post, 5 oktober 1999) – En artikel som ser på frånvaron av allvarliga Y2k-relaterade problem under de första månaderna 1999. Författaren förutspår att ett bara en mindre mängd problem kommer att uppstå vid årsskiftet om tre månader.
 "Y2K bug may never bite" – av John Quiggin (publicerad i "Australian Financial Review", 2 september 1999 – En artikel som inte förutspår några allvarliga problem år 2000 och ser den pågående oron som en överreaktion på Y2K. 
 A Day in the Hype of America – Y2K documentär av Global Griot Productions, filmad i sin helhet under 31 december 1999.

Skämtsamma länkar 
 Y2K, The Millennium Bug. Emailed to me from another humor list (Funny-Bone) Citat: "...15. IRS demands a hundred years of interest from stunned taxpayers...5. Jesus shows up late for His second coming, blames it on COBOL programmers..."
 Millennium bug mini gif-video – Den farliga buggen slår till...

Programfel