Problem roku 2038
Problem roku 2038 (Y2K38, analogicznie do Y2K) – wada oprogramowania, która może ujawnić się 19 stycznia 2038 po godzinie 03:14:07 UTC.
Źródło problemu leży w sposobie zliczania czasu przez niektóre wersje systemu operacyjnego Unix oraz przez oprogramowanie korzystające z tzw. uniksowego timestampu (który bywa także wykorzystywany w systemach operacyjnych i oprogramowaniu niemającym korzeni w systemie Unix). W podatnym na problem oprogramowaniu do przechowywania informacji o punktach w czasie służy 32-bitowa zmienna typu całkowitego ze znakiem (ang. signed integer) zawierająca liczbę sekund, które upłynęły od rozpoczęcia tzw. ery Uniksa, czyli od 1 stycznia 1970, godz. 0:00 UTC. Maksymalna wartość wspomnianej zmiennej wynosi 2 147 483 647 sekund, co odpowiada godzinie 03:14:07 UTC, 19 stycznia 2038. W następnej sekundzie stan licznika stanie się ujemny – nastąpi przeskok do najmniejszej wartości ujemnej (-2 147 483 648) lub licznik zostanie wyzerowany. Wyświetli się wtedy data 13 grudnia 1901 godz. 20:45:52 (przeskok do najmniejszej wartości ujemnej) lub 1 stycznia 1970 godz. 00:00:00 (wyzerowanie licznika Timestamp). Może to spowodować poważne błędy w obliczaniu upływu czasu.
Zagrożenia
edytujProblem 2038 wydaje się o wiele groźniejszy od pluskwy milenijnej z 2000, a także trudniejszy do uniknięcia. Zapobiec mu może przejście na 64-bitową reprezentację czasu (typ time_t), dla której analogiczny problem pojawi się dopiero w roku 292 277 026 596, czyli za około 292 miliardy lat – dla porównania wiek Ziemi szacuje się na 4,5 miliarda lat. Zmiana taka jest już powoli dokonywana[1] i należy się spodziewać, że zostanie zakończona przed rokiem 2038. 64-bitowa reprezentacja czasu zakończy się po upłynięciu (263-1) sekund (9223372036854775807) od rozpoczęcia ery Uniksa.
Problem roku 2038 nie dotyczy systemów z rodziny Microsoft Windows (z wyjątkiem Windows XP, z wyłączeniem Windows XP 64-bit Edition i starszych).
Największym problemem wydaje się nie tyle zmiana samych systemów uniksowych, lecz zmiany potrzebne w oprogramowaniu, które z różnych względów polegało na 32-bitowym rozmiarze zmiennej zawierającej czas. W systemach operacyjnych, w których komponent użytkownika (ang. userland) jest dostarczany wspólnie z jądrem systemu (np. w systemach operacyjnych z rodziny BSD), problem ten może być wyeliminowany poprzez dostosowanie bibliotek systemowych i ponowną kompilację oprogramowania użytkowego. Natomiast w systemie operacyjnym Linux działającym na 32-bitowych architekturach mikroprocesorów, zarówno część użytkownika systemu operacyjnego (np. biblioteka libc), jak i oprogramowanie użytkowe jest dystrybuowane oddzielnie od jądra, częstokroć w postaci binarnej, co utrudnia proces przystosowania zmiennych typu time_t do rozmiaru 64-bitowego.
Zobacz też
edytujPrzypisy
edytuj- ↑ Google Code Archive – Long-term storage for Google Code Project Hosting [online], code.google.com [dostęp 2017-11-26] (ang.).
Linki zewnętrzne
edytuj- [1] – „poprawiona” biblioteka time.h, dla systemów POSIX, gdzie time_t jest 32-bitowe.