A 2000. év problémája

A 2000. év problémája (ismert még mint: a 2000-es év problémája, Y2K-probléma, ezredfordulós bug – angolul Y2K problem, Millennium bug, Y2K bug vagy egyszerűen Y2K) oka a számítástechnikában és más – nem feltétlenül elektronikus – adattárolás során alkalmazott egyszerű fogás volt, hogy a különböző okokból − elsősorban a tárhelyek korlátozott mérete miatt − négy számjegy helyett csak az utolsó két számjegyet használták az évek azonosítására. Ebben a rendszerben a 2000. évet ugyanúgy 00 jelöli, mint az 1900-at, és a legtöbb program tervezésének eredményeként az 1999 után következő 00-át 1900-ként (esetleg 19100-ként vagy 100-ként) értelmezi, ami komoly gondokat okozhat a dátumok összehasonlításával dolgozó rendszerek működésében. Mindez sokáig nem tűnt aggályosnak, a lyukkártyás korszakban, illetve az első számítógépek időszakában jelentős előnyökkel járt, hogy két számjeggyel kevesebbet kellett tárolni. A rövidített évszámok használata az 1960–70-es években programozói mesterfogásnak számított, melynek révén hatékonyabbá lehetett tenni a gépek működését.

Elektronikus kijelző Franciaországban, melyen a 2000. január 3-i dátum helytelenül 1900. évszámmal szerepel

1997-ben a Brit Szabványügyi Intézet (BSI) kifejlesztette a DISC PD2000-1 szabványt, ami meghatározza a 2000. évnek való megfelelés követelményeit az alábbi négy szabály alapján:

1. Semmilyen érvényes dátum nem okozhat szolgáltatáskimaradást.
2. A dátumok közötti különbségek számításának helyesnek kell lennie attól függetlenül, hogy a két dátum különböző évszázadban található-e.
3. Minden interfészen és minden tárolt adatban az évszázadnak egyértelműnek kell lennie, akár explicit meghatározott módon, akár algoritmus által kiszámíthatóan.
4. A 2000-et szökőévként kell kezelnie.

A szabvány két, számítógépes programokban gyakran előforduló problémát azonosított:

• Először is, az évszámok két számjegyen történő tárolása logikai hibákat okoz az x99-ről x00 évre való átforduláskor. Ez egyes dátumokkal dolgozó szoftvereknél hibás működést okozott 2000. január 1-jén és azután, illetve a nagyobb „eseményhorizonttal” dolgozó szoftverek esetében már korábban is. Megfelelő javítás alkalmazása nélkül a hosszú időre tervezett szoftverek meghibásodása volt várható, amikor a „…97, 98, 99, 00…” számsorozat egyszer csak megszűnt monoton növekvőnek lenni.
• Másodszor, egyes programozók félreértették a Gergely-naptár azon szabályát, mely szerint a 100-zal osztható sorszámú évek nem szökőévek – létezik ugyanis egy kiegészítő szabály, mely szerint négyből három 100-zal osztható év valóban nem szökőév, de a 400-zal osztható évek mégiscsak azok. Tehát a 2000. év szökőév volt.

A problémát elsőként Bob Bemer fedezte fel 1958-ban egy genealógiai szoftveren dolgozva, és szóvá is tette azt. A következő két évtizedben a szakértő igyekezett rávenni kollégáit, hogy kezdjenek négy számjegyű évszámokkal operálni, fáradozásait azonban nagyrészt figyelmen kívül hagyták. A programozók többsége elképzelhetetlennek tartotta, hogy az általa írt szoftver még több évtized múlva is használatban lesz, így a precizitás helyett a spórolás mellett tette le voksát, majd a következő generációk tagjai is követték őket ebben. Bár az 1970-es évektől folyamatosan jelentek meg cikkek az „ezredfordulós” dátumproblémával kapcsolatban, a világ nagy része csak az 1990-es évek közepén kapott észbe.

Az államigazgatást, a nagyvállalatokat, azon belül is leginkább a pénzügyi szférát tartották leginkább veszélyeztetettnek. Az évforduló alaposan megkavarhatta volna a kamatszámítást, az értékpapírok, hitelek, bankkártyák futamidejének végét; lejárttá, késedelmessé tehetett volna konstrukciókat, melyek korántsem azok és így tovább.

Az esetleges összeomlás elkerülésére hatalmas összegeket (akkori áron több mint 300 milliárd USD-t) fordítottak világszerte, a vállalatok és más szervezetek megvizsgálták, kijavították és frissítették számítógépes rendszereiket.

Sokak aggodalma ellenére tehát 1999 szilvesztere után valóban nem következett be globális katasztrófa, bár nagy számban jelentkeztek kisebb súlyú, de könnyen javítható meghibásodások (pl. egy 2000. január 1-jén született csecsemőt százévesnek jegyzett fel a kórházi rendszer, és léteztek még 2005-ben is honlapok 19105 dátummal). Megoszlanak a vélemények arról, hogy az Y2K-probléma valóban komolytalan volt, vagy épp ellenkezőleg, a jól elköltött hatalmas pénzösszegek akadályozták meg az összeomlást.

Y2K Magyarországon

A 2000. év problémájával Magyarországon 1996 óta foglalkoztak kormányzati és gazdasági szinten. A témával kapcsolatban az Informatikai Tárcaközi Bizottság többoldalas átfogó tájékoztató anyagot jelentetett meg az interneten. Az első jogszabály 1998-ban jelent meg a 2000. évi évszámmal összefüggő informatikai feladatokról szóló 1059/1998. (V. 8.) Kormányrendelet képében. Ezt egészítette és bővítette ki az 1044/1999. kormányhatározat. A kormány hivatalos közleményként megjelentette cselekvési programját a Magyar Közlöny 1999/61. számában. A közlemény tartalmazza a kormány átfogó Y2K-koncepcióját, és részletesen kidolgozza a probléma szervezeti és egyéb hátterének a biztosítását.

Magyarországon az 1999. március 29-i hatállyal kinevezett dátumváltási vagy évszámkezelési kormánybiztos, Mojzes Imre (1948–2009) felelt a dátumváltással kapcsolatos kormányzati feladatokért.

Aggasztónak tartották a személyi számítógépek BIOS-ának 2000-állóságát, és a beágyazott rendszereket is.

Az Y2K-problémával kapcsolatban a következő kritikus, potenciálisan hibákat okozó dátumokat azonosították:

• 1999. december 31. – Az 1999-es év utolsó napja
• 2000. január 1. – A 2000. év első napja, szombat
• 2000. január 2. – Bankok által javasolt tesztnap
• 2000. január 3. – A 2000. év első munkanapja
• 2000. január 10. – Először 7 jegyűre tömörített dátumforma
• 2000. február 28. – Bankok által javasolt tesztnap
• 2000. február 29. – Rendkívüli szökőnap
• 2000. október 10. – Először 8 jegyű a tömörített dátumforma
• 2001. január 1. – 2001 első napja
• 2001. január 2. – A 2001. év első munkanapja.

Az évszámkezelési problémákkal foglalkozó Kormányzati Koordinációs Irányító Központ harminc stratégiailag fontos ügyelettel tartotta a kapcsolatot, és mintegy 120 ellenőrzőpont információit dolgozta fel. Dátumváltással kapcsolatos zavart sehonnan sem jeleztek.

Programozástechnikai megoldások

A JavaScript .getYear() metódusának Y2K-problémája

Az elavult rendszerek dátumkezelésének kijavítására több, nagyon különböző megoldást találtak ki. Három ezek közül:

Dátumkiterjesztés

a kétjegyű évszámokat az évszázaddal egészítették ki, így a továbbiakban négy jegyen tárolták őket a programokban, fájlokban, adatbázisokban. Ezt tekintették a „legtisztább” megoldásnak, ami egyértelmű dátumokat, időtálló és a továbbiakban alacsony fenntartási költségű programokat eredményezett. Hátránya a magas költségek voltak, mivel a teljes rendszerre kiterjedő, komoly tesztelési és konverziós erőfeszítéseket igényelt.

Dátum-újraparticionálás

az olyan elavult adatbázisokban, ahol az adatmezők értékét nem lehetett gazdaságosan megváltoztatni, a hatjegyű év-hónap-nap kombinációkat átalakították oly módon, hogy az első három jegy az évszámot jelentse (ahol az 1999-et 099-ként, a 2001-et 101-ként tárolták stb.) a következő három jegy pedig az adott nap éven belüli sorszámát jelezte. A dátummezők beviteli és megjelenítési rutinjait frissíteni kellett, de a legtöbb dátumművelethez, és az adatbázis rekordszerkezetéhez nem kellett hozzányúlni. Ez a megoldás egészen a 2899-es évig késlelteti az átfordulási probléma megjelenését.

Dátumablakozás

kihasználva azt, hogy a legtöbb program által használt évszámok viszonylag kis időintervallumon belül maradnak, megtartották a kétjegyű évszámokat, és a programok csak akkor foglalkoztak az évszázad értékével, ha az adott feladathoz szükség volt rájuk, például dátumok összehasonlításakor (az évszázad „ablaka” arra a 100 éves időtartamra utal, amibe a használt dátumok mind beleesnek). Ez a technika, ami a programok kisebb patchelését igényelte, sokkal könnyebben implementálható és tesztelhető volt, mint a dátumkiterjesztés, így sokkal olcsóbb is volt annál. Bár nem tekinthető végleges megoldásnak, évtizedekig működőképes lehet. Ezt megfelelőnek gondolták, abban reménykedve, hogy a régebbi, elavult rendszerek végül csak kiváltásra kerülnek újabb technológiákkal.

Kapcsolódó szócikkek

• 2038-probléma

Fordítás

• Ez a szócikk részben vagy egészben a Year 2000 problem című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

További információk

• iPon: Változatok végnapokra − A Y2K és más elmaradt világvégék
• 24.hu: A 2000. év problémája – A nagy kétség
• Index: Az Y2010 az új Y2K
• Hetek 2000. január 8-i száma: Szabadi Sándor: Nagy üzlet volt a dátumváltás
• Az Y2K-probléma külföldön – A külföldi jog fejleményei lépésről-lépésre… (A Magyar Hivatalos Közlönykiadó multimédia alapú tájékoztató kiadványa az érintett felhasználóknak)
• KFKI-linkgyűjtemény

Kapcsolódó szócikkek

• Időábrázolással kapcsolatos problémák