W roku 2000 błąd Y2K pojawił się i zniknął bez wielu problemów. Mimo przewidywań powszechnej awarii, kryzys został zażegnany zarówno dzięki długofalowemu planowaniu, jak i interwencji w ostatniej chwili, a żaden z krytycznych systemów nie zawiódł. W ciągu ostatnich lat te nieliczne systemy operacyjne i aplikacje, które ucierpiały, zostały w większości przypadków uaktualnione, zastąpione lub wycofane z użytku.
Jeśli używasz systemu opartego na Uniksie lub Linuksie, jest jeszcze jeden błąd związany z datą, o który będziesz musiał się martwić — w roku 2038.
We wszystkich 32-bitowych systemach opartych na Uniksie/Linuksie czas zegara systemowego jest przechowywany wewnętrznie jako liczba sekund od czasu Epoch, czyli 00:00:00 1 stycznia 1970 roku. Ten wewnętrzny typ danych, time_t, jest w większości przypadków 32-bitową (4-bajtową), podpisaną liczbą całkowitą. Jeśli system, o którym mowa, jest zgodny ze standardem POSIX (jak większość systemów Unix i Linux), ostatni czas i data, które mogą być reprezentowane jako seconds-since-the-Epoch w 32-bitowej podpisanej liczbie całkowitej, to 3:14:07 UTC we wtorek 19 stycznia 2038 roku.
Po tym czasie i dacie wewnętrzna reprezentacja czasu systemowego osiągnie 2147483647, najwyższą liczbę możliwą do przechowywania w 32-bitowej podpisanej liczbie całkowitej. Jedną sekundę po tym, dojdzie do liczby ujemnej, -2147483648. Obecne aplikacje albo zinterpretują tę ujemną liczbę jako starszy rok (1901), albo zamrożą zegar systemowy na 03:14:07 w dniu 1/19/2038. Może to spowodować awarię aplikacji i systemów operacyjnych, ponieważ nie są one zaprojektowane do pracy z zawieszonym zegarem systemowym lub takim, który pokazuje rok 1901.
Nie ma realnych poprawek (które nie zepsują istniejących aplikacji) dla systemów korzystających z procesorów 32-bitowych lub systemów operacyjnych i aplikacji działających w trybie 32-bitowym na procesorach 64-bitowych. Wiele obecnych systemów operacyjnych Unix/Linux działa już w trybie 64-bitowym (z odpowiednim „długim” time_t) na procesorach 64-bitowych; w większości przypadków rozwiązuje to problem.
Systemy operacyjne, które obsługują długi 64-bitowy time_t, najprawdopodobniej nie są dotknięte błędem Roku 2038, jeśli chodzi o wewnętrzny zegar systemowy. Jednak aplikacje korzystające z 32-bitowego time_t mogą nadal zawodzić, nawet jeśli system, na którym działa aplikacja, obsługuje w pełni 64-bitowe operacje.
Oto szybki przegląd aktualnego stanu obsługi Uniksa 2038 w głównych wydaniach systemu Unix/Linux:
- Solaris 7 lub nowszy na 64-bitowych procesorach UltraSPARC i SPARC64, a także Solaris 10 na platformach x86-64, ma 64-bitowy time_t.
- AIX w wersji 4.3.3 na 64-bitowych procesorach PowerPC i Power ma 64-bitowy time_t.
- Jądro Linux działające w trybie 64-bitowym na procesorach IA64 lub x86-64 ma 64-bitowy time_t.
- Mac OS X w wersji 10.4 i nowszej ma 32-bitowe jądro, ale aplikacje mogą używać 64-bitowego time_t, gdy działają na procesorach PowerPC G5 lub x86-64.
- FreeBSD 6.0 i nowsze ma 64-bitowy time_t, gdy działa na platformie 64-bitowej.
- OpenBSD 4.1 i nowsze obsługują 64-bitowy time_t.
- NetBSD nie posiada jeszcze 64-bitowego time_t, ale trwają prace nad rozwiązaniem tego problemu w nadchodzącym wydaniu.
Nawet jeśli twój obecny system operacyjny nie jest jeszcze bezpieczny dla Uniksa 2038, nie martw się! Ludzie są świadomi tego problemu już od wielu lat i aktywnie pracują nad jego rozwiązaniem. W większości przypadków problem zostanie rozwiązany poprzez uruchomienie systemu operacyjnego i aplikacji w trybie w pełni 64-bitowym.
Spodziewam się, że wszystkie główne systemy operacyjne dla komputerów stacjonarnych będą w pełni 64-bitowe w ciągu najbliższych pięciu do dziesięciu lat. Dodatkowo, efekt „trickle down” pomoże zastąpić obecne systemy konfiguracjami 64-bitowymi tam, gdzie będzie to możliwe do zastosowania i opłacalne.
OPOWIEŚĆ O AUTORZE: Bill Bradford jest twórcą i opiekunem SunHELP i mieszka w Houston, w Teksasie, wraz z żoną Amy.
.