thumb|Elektronikus kijelző Franciaországban, melyen a 2000. január 3-i dátum helytelenül 1900. évszámmal szerepel 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.iPon: Változatok végnapokra − A Y2K és más elmaradt világvégék
1997-ben a Brit Szabványügyi Intézet (BSI) kifejlesztette a DISC PD2000-1 szabványt,BSI Standard , on year 2000, visszavonva 2005-ben 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-tY2K: Overhyped and oversold?, report from BBC News, 6 January 2000) 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.Magyar Közlöny 1999. évi 61. szám, PDF 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.Magyar Hírlap: A világvége technikai okok miatt elmaradt (összeállítás, 2000. január 14., péntek)
Programozástechnikai megoldások thumb|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."The Case for Windowing: Techniques That Buy 60 Years", article by Raymond B. Howard, Year/2000 Journal, Mar/Apr 1998.
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 Kategória:Szoftverhibák Kategória:Naptárak