A 2000. év problémája

A Wikipédiából, a szabad enciklopédiából
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.[1]

1997-ben a Brit Szabványügyi Intézet (BSI) kifejlesztette a DISC PD2000-1 szabványt,[2] 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.[3]

Az esetleges összeomlás elkerülésére hatalmas összegeket (akkori áron több mint 300 milliárd USD-t[4]) 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.[1]

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[szerkesztés]

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.[5] A kormány hivatalos közleményként megjelentette cselekvési programját a Magyar Közlöny 1999/61. számában.[6] 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.[5]

Magyarországon az 1999. március 29-i hatállyal kinevezett[5] 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.[7]

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.[5]

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.[5]

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.[8]

Programozástechnikai megoldások[szerkesztés]

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.[9]

Kapcsolódó szócikkek[szerkesztés]

Jegyzetek[szerkesztés]

  1. ↑ a b iPon: Változatok végnapokra − A Y2K és más elmaradt világvégék
  2. ↑ BSI Standard Archiválva 2016. március 4-i dátummal a Wayback Machine-ben, on year 2000, visszavonva 2005-ben
  3. ↑ 24.hu: A 2000. év problémája – A nagy kétség. [2016. március 6-i dátummal az eredetiből archiválva]. (Hozzáférés: 2016. január 7.)
  4. ↑ Y2K: Overhyped and oversold?, report from BBC News, 6 January 2000
  5. ↑ a b c d e Cégvezetés: Mi az Y2K? (Megjelent a Cégvezetés 1999. október 1-jei, 19. számában). [2013. április 7-i dátummal az eredetiből archiválva]. (Hozzáférés: 2016. január 7.)
  6. ↑ Magyar Közlöny 1999. évi 61. szám, PDF[halott link]
  7. ↑ A Magyar Tudomány nekrológja. [2010. április 18-i dátummal az eredetiből archiválva]. (Hozzáférés: 2016. január 7.)
  8. ↑ Magyar Hírlap: A világvége technikai okok miatt elmaradt (összeállítás, 2000. január 14., péntek)[halott link]
  9. ↑ "The Case for Windowing: Techniques That Buy 60 Years", article by Raymond B. Howard, Year/2000 Journal, Mar/Apr 1998.

Fordítás[szerkeszté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[szerkesztés]

Kapcsolódó szócikkek[szerkesztés]

A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=A_2000._év_problémája&oldid=22140501”