Emlékszünk még az Y2K-pánikra? Ma már csak vigyorgunk, ha véletlenül belefutunk a korabeli Y2K-témájú híradások, vagy csodálatosan gagyi katasztrófafilmek egyikébe, de annak idején a becslések szerint 300 milliárd dollárt költöttek arra világszerte a számítógépes hálózatok fenntartói, hogy a dátumváltástól ne omoljon össze a tőzsde, a gazdaság, a forgalomirányító rendszerek, meg úgy általában minden, amiben számítógép van. Szó se róla, nem is omlott. Aztán tíz év múlva, 2009-2010 fordulóján eljött az Y2010-válság, ami ugyan nem volt ennyire túllihegve, mondhatni agyon lett hallgatva, mégis több tízmillió embert érintett világszerte.
Az Y2K- és az Y2010-probléma egyaránt azért létezhetett, mert a programozók sokkal inkább spórolós emberek, mint amennyire előrelátók. A spórolással nincs is semmi baj, hiszen ha kitalálják, hogy mondjuk az évszámoknak elég csak az utolsó két számjegyét tárolni, és azokkal számolni, annak az a következménye, hogy kevesebb memóriát eszik az operációs rendszer és gyorsabbak lesznek a dátumokkal végzett műveletek. És ötvenes-hatvanas években, amikor ezt kitalálták, két számjegy megspórolása még nagyon sokat jelentett a dög lassú, és szobányi méretű számítógépeknek.
Viszont – és itt jön be a képbe az előrelátás hiánya –, amikor 1999-ről 2000-re vált a naptár, a rendszer ebből csak annyit fog látni, hogy 00, és úgy értelmezi, hogy újra 1900-at írunk, amiből aztán elég fura következtetéseket vonnak le a programok, amiknek szükségük van erre az adatra.
Illetve vonhattak volna le, mert jött '99-ben a pánik (bár tulajdonképpen már a nyolcvanas évek közepe óta dolgoztak az ügyön a szakemberek), a 300 milliárd dollár, míg végül az Y2K-hiba következményei megragadtak azon a szinten, hogy a sarki videotéka rendszere kiszámlázott 99 évnyi kölcsönzési díjat a január első napjaiban visszavitt filmekért. És most tekerjünk előre tíz évet az időben, 2010. januárjának elejére.
Németországban 30 millió bankkártya vált használhatatlanná újév napján, mert az ATM-ek és más automaták úgy gondolták, hogy lejárt az érvényességi idejük. Ausztráliában POS-automaták zavarodtak meg, mert a belső órájukon a dátum 2010 helyett 2016-ra ugrott. A Symantec biztonságtechnikai cég NAC (network access control) rendszere szintén elnézte a dátumot, és hirtelen az összes vírus- és spammintát több évesnek kezdte látni, ami miatt természetesen beriasztott, hogy frissíteni kéne az adatbázist (hasonlóan járt a SpamAssassin spamszűrő rendszer is).
Az SAP vállalatirányítási szoftverben a nyomtatási kérelmek lejárati dátuma állt át 2100-ra, így a rendszer nem törölte őket teljesítés után, amitől túlcsordult az egész nyomtatási alrendszer. Szerte a világon változatos mobilszolgáltatók ügyfelei jelezték, hogy az újévi üdvözlő sms-eket 2016-os dátummal kapják meg. A Palm Pre telefonok megtagadták a számítógéppel való szinkronizációt. És ez csak néhány eset a Networkworld jelentéséből, ami az Y2010 problémával foglalkozik.
A 2010-es év problémája a bináris és a BCD (binárisan kódolt decimális) számábrázolási módszerek különbözőségéből fakad. A bináris kódolás azt jelenti, hogy minden számot kettes számrendszerben tárolunk, nullásokkal és egyesekkel írunk le; ma minden digitális eszköz ezen az elven működik. A BCD ennek speciális fajtája, egy jellemzően régebben, főleg az IBM által használt kód, amiben a tízes számrendszer szerinti helyiértékeket egyenként kódoljuk le kettes számrendszerbe. Egytől kilencig nincs probléma, ugyanúgy néz ki mind a két kód, tíznél jön a gond. Ami binárisan így néz ki: 1010 (egyszer nyolc + nullaszor négy + egyszer kettő + nullaszor egy), BCD-ben meg így: 0001 0000 (vagyis a tízes első számjegye mint egyszer egy, és utána a második számjegye csupa nullából).
Ha egy bináris rendszer kap egy tízest (ami a 2010-es dátum beköszöntével egyszer csak roppant gyakori lett) egy BCD rendszerből, 16-nak fogja látni, fordítva viszont a BCD rendszer nem is képes értelmezni, mit jelent a bináris tízese. Hát ezért váltott szilveszter éjfélkor éppen 2016-ra a dátum a már említett sms-ekben, és automatákban: egyes rendszerek nem voltak felkészítve arra, hogy BCD-ből binárisba kell átváltani a számokat, ami kilenc évig nem is tűnt fel senkinek.
A 2010-es év problémáját mindenesetre különösebb katasztrófák nélkül átvészelte a világ, és úgy néz ki, most 28 évig nyugtunk lesz az efféle problémáktól. 2038. január 19-én hajnalban (egész pontosan greenwichi idő szerint 3 óra 14 perc 7 másodperckor) aztán eljön a Unix-armageddon.
A régebbi, Unix-alapú rendszerekben az óra egy egyszerű számlálón alapul, ami 1970. január elsején éjféltől számolja az eltelt másodperceket, és ebből a számból képez aztán dátumot, órát-percet-másodpercet. A számláló 32 bites formátumot használ, de a mérnökök annak idején – ki tudja miért – előjeles formátumot használtak, így tulajdonképpen csak a felét használja ki az óra az elérhető számtartománynak. 32 biten kettő a harminckettediken szám fér el, ennek a fele elmegy a negatív számokra, a további matekot most átugorjuk, aki nem hiszi járjon utána: az indítás után 2 147 483 647 másodperccel, a már említett 2038-as januári hajnalon túlpörög a számláló, és nulláról kezdi újra, a gép meg azt fogja hinni, hogy újra 1970 van, és ezzel az adattal hülyít meg minden szoftvert.
Egészen 2031-ig okozhat még félreértéseket a különböző országokban használatos dátumformátumok különbözősége (pontosabban utána is, de 2032-től kevesebb ilyenre lesz alkalom, mert egyetlen hónapban sincs harminckettedike); az év, a hónap és a nap sorrendjére más sorrendet ír elő a hagyomány a világ más-más tájain. 10/01/19 például nálunk 2010. január 19-et jelent, Amerikában 2019. október elsejét, Nyugat-Európa legtöbb országában meg 2019. január 10-et.
Az ISO 8601-es számú szabványa a nálunk is használt év-hó-nap sorrendet preferálja, de mint a wikipédia térképén is látszik, nem sok hatással.
A mai rendszerekben már 64 bitet adnak a számláló tárolására, amiben 292 milliárd évre elég hely van a számoknak, de valamit tenni kell a régebben legyártott 32 bites darabokkal is, amelyek főleg beágyazott rendszerekben dolgoznak, többek között erőműveket vagy közlegedési rendszereket irányító célszámítógépekben. 64 bitesre átállítani utólag az óra formátumát rettenetes galibákat okozna minden szoftverrel, adatbázissal történő kommunikációban. Az előjeles 32 bites módot átkapcsolni előjel nélkülire időt nyerne 2106-ig, de akkor meg az 1970 előtti dátumok kezelésével lenne gond.
A problémára egyelőre nincs általánosan elfogadott megoldás, így legfeljebb reménykedhetünk, hogy 28 év alatt csak kitalálnak rá valamit, vagy addigra egyszerűen kikopik a használatból minden olyan rendszer, amiben 32 bites óra van.
Bár a számítógépek nem hülyültek meg tőle (csak az emberek egy kicsit), tíz éve parázs, és teljesen parttalan viták forrása volt a kérdés, hogy az új évezred 2000-ben, vagy 2001-ben kezdődik. Most megismételte magát a történelem: menetrendszerűen elindult a vita, hogy 2010 még az előző, vagy már a következő évtizedhez tartozik.
Ugyan az évtized a hivatalos definíció szerint bármely tíz összefüggő évet jelentheti a naptárban, az általánosan elfogadott szokás szerint a tized első számjegye számít, vagyis idén már a 2010-es évtized első évét írjuk, nem a 2000-esből az utolsót. Ez persze azt is jelenti, hogy valahol el kell spórolni egy évet, hiszen az időszámítás az 1. évvel kezdődik, nem a nulladikkal. Így ha ehhez az elmélethez tartjuk magunkat, azt is el kell fogadni, hogy az első évtized csak kilenc évig tartott. Lehet hogy logikátlan, de legalább ennyire logikátlan az is, hogy mondjuk 1970-et nem tekintjük a hetvenes évek részének. Két logikátlanság között meg talán jobb amellett dönteni, amit már amúgy is megszoktunk.