Más néven Y2K38 hiba, Unix Y2K hiba vagy Epochalypse.
A számítástechnikában a 2038-as év problémája néhány szoftver meghibásodását okozhatja 2038-ban vagy akörül. A probléma a POSIX időábrázolást használó programokat érinti elsősorban, amely az időt az 1970. január 1. óta eltelt másodpercek számával ábrázolja. Ez az ábrázolási mód számít szabványnak a Unix típusú operációs rendszereknél, de érinti az egyéb operációs rendszerekre fejlesztett programok nagy részét, mivel a széles körben használt C programozási nyelv is ezt az ábrázolási módot használja. A legtöbb 32 bites rendszerben, a time_t adattípus, melyet a másodpercszámláló tárolására alkalmaznak, egy előjeles, 32 bites integer (egész szám) formátumú adat. A legkésőbbi időpont, amely még ábrázolható ebben a rendszerben a POSIX szabvány szerint 2038. január 19., kedd, 03:14:07 (UTC szerinti idő). Ezt követően az időpontok „körbefordulnak”, és belsőleg negatív számként jelennek meg, amely helyzet a programok meghibásodásához vezet. Mivel az időpontokat nem 2038-ra fogják tenni, hanem 1970-be vagy 1901-be, ez okból kifolyólag hibás számításokat és hibás döntéseket fog hozni a program. Ezekkel kapcsolatos javításokat is eszközöltek az új Linux Kernelekben a fejlesztők. (link)
Hogy megértsük, miért történik ez, meg kell értenünk, hogyan tárolják ezeket a dátumokat.
Mely dátumokat érinti ez a probléma?
Az egyik módja annak, ahogy a dátumokat egy rendszerben tárolják, az úgynevezett Unix-időbélyeg, Unix-epoch idő vagy egyszerűen időbélyeg. Ezek a dátumok az 1970. január 1. éjfél (UTC/GMT) óta eltelt másodpercek számaként vannak tárolva.
Ha egy előjeles (signed) 32 bites egész számot használnak ennek a típusú dátumnak a tárolására, akkor az 2038. január 19-én 03:14:07 UTC után kifogy a helyből a dátumok tárolására. Ez hibát okozhat vagy helytelen időt tárolhat, attól függően, hogy milyen nyelven írták (például PHP vagy C), milyen verzióról van szó, az operációs rendszertől és sok más tényezőtől függően. Itt van egy példa arra, hogy a dátum visszaugrik 1901-re.
Fontos megjegyezni, hogy ez a probléma nem csak a UNIX rendszereket érinti, mivel sok programozási nyelv és rendszer átvette ezt a dátumformátumot az idő ábrázolására.
Ha nem érted, mi az az előjeles 32 bites egész szám, javasoljuk, hogy olvasd el útmutatónkat: „Ismerd meg, hogyan tárolják a számítógépek az egész számokat.”
Hogyan ellenőrizhetem, hogy ez probléma lesz-e?
Ennek az ellenőrzése az egész rendszeren valószínűleg időigényes és bonyolult feladat lesz. Meg kell vizsgálnod a rendszer minden aspektusát és mindent, ami ehhez a rendszerhez csatlakozik. Fontos megjegyezni, hogy ezek a problémák néhány rendszerben korábban, másokban később fordulhatnak elő, ha a rendszer a jövőbeli és múltbeli időket hasonlítja össze.
Minden rendszer más, és lehetetlen lenne egy teljes listát összeállítani arról, hogy mit kell ellenőrizni, de itt van néhány dolog, amire figyelned kell:
- Beágyazott rendszerek, amelyek dátumokat előjeles (signed) 32 bites egész számú időbélyegekként tárolnak
- Olyan hardverek, amelyek 32 bites szoftvert vagy operációs rendszert futtatnak
- Adatbázisok, amelyek időbélyegeket tárolnak előjeles (signed) 32 bites egészekként
- Adatbázis-függvények, amelyek 32 bites egész számú időábrázolást használnak, mint például a UNIX_TIMESTAMP()
- Kódok, ahol dátumokat, időket vagy két idő közötti intervallumokat hasonlítanak össze
- Kódok, amelyek a jövőbeli vagy múltbeli időkre vagy eseményekre alapoznak számításokat. (Például egy kölcsönkalkulátor, amely 30 évre számít kamatot)
Szükséged lesz szakértőkre, hogy ellenőrizzék az összes rendszert, különösen, ha olyan kritikus szoftvereket futtatsz, amelyek nem engedhetik meg maguknak, hogy bármennyi időre is leálljanak.
Ha minden szoftvered 64 bites, az nem garantálja, hogy nem lesz problémád. Még ezekben a rendszerekben is tárolhatnak dátumokat előjeles (signed) 32 bites egészekkel, és ezek a rendszerek függhetnek más rendszerektől, amelyeknél előfordulhat ez a probléma.
Fontos megjegyezni, hogy nem minden 32 bites szoftver fogja ezt a problémát mutatni; valójában a 32 bites szoftverek túlnyomó többsége valószínűleg nem fogja ezt a problémát tapasztalni. Sok 32 bites szoftver speciális struktúrákban tárolja a dátumokat, amelyek képesek kezelni a 2038 utáni dátumokat, de az egyetlen módja annak, hogy biztosan tudd, hogyan tárolják és használják a dátumokat egy rendszerben, ha ellenőrzöd.
Egy figyelmeztetés: ne változtass időt a szervereken tesztelés céljából, egyszerűen ne tedd. Ha tényleg tudod, mit csinálsz, akkor is csak óvatosan folytasd. Ha a szerverek ideje kiesik a szinkronból, rossz dolgok történhetnek. Próbálj meg minden tesztet tesztrendszereken elvégezni, és ne éles szervereken, hogy minimalizáld a hatásokat, és ha valóban tesztelned kell éles gépeken, akkor olyan időpontokban tedd, amikor a rendszerek nem annyira elfoglaltak, arra az esetre, ha valami elromlik. Hogyan lehet megoldani ezt a problémát?
Nincs univerzális megoldás erre a problémára. A rendszereket teljes mértékben ellenőrizni kell, a problémákat azonosítani és javítani kell. Javasolt, hogy extra teszteket adj hozzá határidős tesztekkel ez körül a dátum körül, hogy biztosítsd, hogy a szoftver működni fog ezen dátum után is.
Miután a problémákat azonosították, itt van néhány módja annak, hogyan lehet őket kijavítani:
- Az időbélyegeket és a függvényeket alakítsd át 64 bites egészek használatára (és győződj meg arról, hogy a függvények helyesen kezelik a 64 bites egészeket)
- Alakítsd át a kódot nem előjeles 32 bites egészek használatára, ahol nincs szükség dátumok tárolására 1970 előtt. Ne feledd, hogy ezzel csak elodázod ugyanazt a problémát 2106. február 7-re.
- Az időbélyegeket alakítsd át kifejezetten időpontok és dátumok kezelésére létrehozott struktúrák használatára (például DateTime objektumok).
Ez hasonló a Y2K hibához?
Bizonyos szempontból hasonló típusú probléma, mint a Y2K hiba, mivel a dátumot olyan módon tárolják, amely nem rendelkezik elég nagy kapacitással, hogy egy adott dátum után reprezentálja az időt. Ez a hasonlóság az oka annak, hogy néha Y2K38 hibának is nevezik. A Y2K hiba az volt, amikor az éveket '00'-ként tárolták '2000' helyett, míg a 2038-as év problémája az, hogy az alapul szolgáló struktúra nem elég nagy ahhoz, hogy tárolja a 2038 utáni dátumokat. Ez a világ végét fogja okozni?
Valószínűleg nem. 2038-ra a legtöbb szoftvert frissíteni kell, hogy legalább 64 bites időbélyeg ábrázolást használjon. Kritikus rendszerek esetében a legtöbbjüknek át kell vizsgálnia a kódjaikat és rendszereiket, és végre kell hajtaniuk a szükséges javításokat még ezen dátum előtt. Ezenkívül a Y2K hiba kijavítása előtt végzett munka során a dátumproblémák körüli munkának figyelembe kellett vennie a 2038-as problémát is.
Ez nem jelenti azt, hogy teljesen figyelmen kívül hagyhatod, de hacsak nincsenek nagy mulasztások vagy a cégek nem hagyják figyelmen kívül a problémát,
