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.

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:
 Semmilyen érvényes dátum nem okozhat szolgáltatáskimaradást.
 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.
 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.
 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

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

Jegyzetek

Fordítás

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

Problémája
Szoftverhibák
Naptárak
A év problémája ( ismert még mint : aes é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 évet ugyanúgyjelöli , mint azat , és a legtöbb program tervezésének eredményeként azután következőátként ( esetlegként vagyké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 az70-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 . 1997-ben a Brit Szabványügyi Intézet ( BSI ) kifejlesztette a DISC PD2000-1 szabványt , ami meghatározza a évnek való megfelelés követelményeit az alábbi négy szabály alapján : Semmilyen érvényes dátum nem okozhat szolgáltatáskimaradást . 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 . 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 . Aet 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 januárjé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,” 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 azal osztható sorszámú évek nem szökőévek – létezik ugyanis egy kiegészítő szabály , mely szerint négyből háromzal osztható év valóban nem szökőév , de azal osztható évek mégiscsak azok . Tehát a év szökőév volt . A problémát elsőként Bob Bemer fedezte felban 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 azes évektől folyamatosan jelentek meg cikkek az „ ezredfordulós” dátumproblémával kapcsolatban , a világ nagy része csak azes é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 mintmilliá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átszilvesztere 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 januárjén született csecsemőt százévesnek jegyzett fel a kórházi rendszer , és léteztek mégben is honlapokdá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 év problémájával Magyarországonó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ályban jelent meg a évi évszámmal összefüggő informatikai feladatokról szóló1998. ( V . ) Kormányrendelet képében . Ezt egészítette és bővítette ki az1999. kormányhatározat . A kormány hivatalos közleményként megjelentette cselekvési programját a Magyar Közlöny61. 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 márciusi hatállyal kinevezett dátumváltási vagy évszámkezelési kormánybiztos , Mojzes Imre2009 ) 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á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 : december – Azes év utolsó napja január – A év első napja , szombat január – Bankok által javasolt tesztnap január – A év első munkanapja január – Előszörjegyűre tömörített dátumforma február – Bankok által javasolt tesztnap február – Rendkívüli szökőnap október – Előszörjegyű a tömörített dátumforma január –első napja január – A é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 mintegyellenőrzőpont információit dolgozta fel . Dátumváltással kapcsolatos zavart sehonnan sem jeleztek . Programozástechnikai megoldások 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 azetként , aetké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 aes é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é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 probléma Jegyzetek Fordítás További információk iPon : Változatok végnapokra − A Y2K és más elmaradt világvégék hu : A év problémája – A nagy kétség Index : Az Y2010 az új Y2K Hetek januári 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 Problémája Szoftverhibák Naptárak