2000-ben az Y2K hiba jött és ment sok probléma nélkül. A széleskörű meghibásodásra vonatkozó előrejelzések ellenére a válságot mind hosszú távú, mind az utolsó pillanatban történő tervezéssel és beavatkozással sikerült elkerülni, és egyetlen kritikus rendszer sem hibásodott meg. Az azóta eltelt években azt a néhány operációs rendszert és alkalmazást, amely érintett volt, a legtöbb esetben frissítették, lecserélték vagy nyugdíjazták.
Ha Unix- vagy Linux-alapú rendszert használ, akkor még egy dátummal kapcsolatos hiba miatt kell aggódnia — a 2038-as évben.
Minden 32 bites Unix/Linux-alapú rendszer a rendszeróra idejét belsőleg az epocha óta eltelt másodpercek számaként tárolja, vagyis 1970. január 1-jén 00:00:00-kor. Ez a belső adattípus, a time_t, a legtöbb esetben 32 bites (4 bájtos) előjeles egész szám. Ha a szóban forgó rendszer a POSIX szabványt követi (mint a legtöbb Unix és Linux rendszer), akkor a legkésőbbi idő és dátum, amely a 32 bites előjeles egész számban a másodpercek a korszak óta számítva ábrázolható, 2038. január 19-én, kedden, 3:14:07 UTC.
Az idő és dátum után a rendszeridő belső ábrázolása eléri a 2147483647-et, a 32 bites előjeles egész számban tárolható legnagyobb számot. Egy másodperccel ezután egy negatív számig, -2147483648-ig fog kitekeredni. A jelenlegi alkalmazások ezt a negatív számot vagy egy régebbi évszámként (1901) értelmezik, vagy a rendszerórát 2038. január 19-én 03:14:07-re fagyasztják. Ez valószínűleg az alkalmazások és az operációs rendszerek meghibásodását fogja okozni, mivel azokat nem úgy tervezték, hogy megakadt rendszerórával vagy 1901-es évszámmal működjenek.
Nincsenek életképes (a meglévő alkalmazásokat nem tönkretevő) megoldások a 32 bites processzorokat használó rendszerek, illetve a 64 bites processzorokon 32 bites üzemmódban futó operációs rendszerek és alkalmazások számára. Sok jelenlegi Unix/Linux operációs rendszer már 64 bites üzemmódban fut (megfelelő “hosszú” time_t-vel, ha 64 bites processzoron; a legtöbb esetben ez megoldja a problémát.
A hosszú 64 bites time_t-t támogató operációs rendszereket valószínűleg nem érinti a 2038-as év hibája a belső rendszeróra szempontjából. A 32 bites time_t-t használó alkalmazások azonban még akkor is meghibásodhatnak, ha az alkalmazást futtató rendszer támogatja a teljes 64 bites működést.
Itt egy gyors áttekintés a Unix 2038 támogatásának jelenlegi helyzetéről a mainstream Unix/Linux kiadásokban:
- A Solaris 7 vagy újabb 64 bites UltraSPARC és SPARC64 processzorokon, valamint a Solaris 10 x86-64 platformokon 64 bites time_t-vel rendelkezik.
- Az AIX 4.3.3 verziója 64 bites PowerPC és Power processzorokon 64 bites time_t-vel rendelkezik.
- A 64 bites üzemmódban IA64 vagy x86-64 processzorokon futó Linux kernel 64 bites time_t-vel rendelkezik.
- A Mac OS X 10.4-es és újabb verziója 32 bites kernellel rendelkezik, de az alkalmazások 64 bites time_t-t használhatnak, ha PowerPC G5 vagy x86-64 processzorokon futnak.
- A FreeBSD 6.0 és újabb verziója 64 bites time_t-vel rendelkezik, ha 64 bites platformon fut.
- Az OpenBSD 4.1 és újabbak támogatják a 64 bites time_t-t.
- ANetBSD még nem rendelkezik 64 bites time_t-vel, de már folynak az erőfeszítések a probléma megoldására egy következő kiadáshoz.
Még ha a jelenlegi operációs rendszere még nem Unix 2038 biztonságos, ne aggódjon! Az emberek már évek óta tisztában vannak a problémával, és aktívan dolgoznak a megoldáson. A legtöbb esetben a probléma úgy oldódik meg, hogy az operációs rendszer és az alkalmazások végül teljes mértékben 64 bites üzemmódban futnak majd.
Várakozásaim szerint a következő 5-10 évben minden nagyobb asztali operációs rendszer teljesen 64 bites lesz. Ezen kívül a csepegtető hatás segíteni fogja a jelenlegi rendszerek 64 bites konfigurációkra való cseréjét, ahol ez alkalmazható és költséghatékony.
A szerzőről: Bill Bradford a SunHELP megalkotója és karbantartója, a texasi Houstonban él feleségével, Amyvel.