Ciekawostka - problem roku 2038
wada oprogramowania, która może się ujawnić 19 stycznia 2038. Ź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 nie mają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. Problem 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 (2^64-1) sekund ('9223372036854775808) od rozpoczęcia epoki Unix. Problem roku 2038 nie dotyczy systemów Windows (z wyjątkiem Windows XP 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. Oprogramowanie takie spotykane jest na przykład w systemach bankowych i ubezpieczeniowych[2].
Strona wykonana przez : Sebastian Kokosza 2016©