Problem roku 2000 nam nie zaszkodził. Nadchodzi problem roku 2038
Niedawno na jednym z naszych serwerów nastąpiła ciekawa awaria. Kilka tekstów zostało w magiczny sposób przeniesionych w czasie do stycznia 1970 roku. Konkretnie do 1. stycznia 1970 roku. Istnieje racjonalne i proste wyjaśnienie, dlaczego tak się stało.
Aby to zrozumieć, musimy najpierw zastanowić się, dlaczego daty, to prawdziwy koszmar dla systemów informatycznych.
Problem z datą
Data, wraz z czasem, jest bardzo złożonym typem danych dla komputerów. Nie dość, że ta sama godzina ma różne reprezentacje w różnych miejscach świata, to sama implementacja np. liczenia różnicy dat w jakimkolwiek języku programowania, jest bardzo skomplikowana. Dlaczego? Wyobraźcie sobie tylko - dodawanie dni powoduje zwiększenie się miesiąca czasami po przekroczonych 28, 30, a czasami 31 dniach. Czasami 29 dniach. Minuty dodajemy do godziny, przepełnia się ona po przekroczeniu 60 minut. Za to dzień przekraczamy, gdy przekroczymy 24 godziny. I tak dalej, i tak dalej.
Nie wspominam już o tym, że ludzkość od lat nie może się dogadać co do czytelnej reprezentacji daty i godziny. W Niemczech i Polsce 17:15 jest normalną godziną, za to dla Anglika wygląda to jak coś z Roku 1984 Orwella. To właśnie tam autor straszył londyńczyków wizją niepojętej i nieludzkiej godziny trzynastej już w pierwszym zdaniu. Anglicy i Amerykanie z kolei zapiszą godzinę za pomocą jednej bądź dwóch cyfr i dodadzą PM lub AM - czasami z odstępem po godzinie, a czasami nie.
To zaledwie początek problemów z datą. Nic dziwnego, że dla komputerów, które domyślnie pracują na liczbach, ten złożony typ danych jest koszmarem. Stąd w historii informatyki stosowano różne uproszczenia - np. zapisywano datę z rokiem zawsze jako dwucyfrowym jej fragmentem, co prowadziło do tzw. problemu roku 2000.
Data jako liczba
To właśnie dlatego w latach 70., gdy powstawały pierwsze systemy Uniksowe, zadbano o to, aby zapisać dokładnie datę z czasem za pomocą jednej liczby całkowitej. Jest to tzw. Unix time, czyli czas uniksowy. Jest on określony jako liczba sekund, która minęła od północy 01.01.1970. Nawet to jest uproszczeniem, bo w pierwszej edycji Unix Programmer's Manual z 1971 roku miało to być zliczanie co 1/60 sekundy. Programiści jednak szybko zorientowali się, że dostępna wtedy liczba 32-bitowa potrafi zmieścić zaledwie 2,5 roku dat. Zmieniono to wtedy na mniej dokładne - sekundowe podawanie dat. W ten sposób można zapisać w 32-bitowej liczbie około 136 lat, z czego połowę przed 1 stycznia 1970 (liczby ujemne), a połowę po tej dacie (liczby dodatnie).
Tym sposobem osiągnięto bardzo ciekawą rzecz - za pomocą jedynie czterech bajtów jesteśmy w stanie określić datę i czas (tzw. timestamp) z dokładnością do sekundy. Uważni czytelnicy zauważą od razu dwa problemy:
- Nie ma tu informacji o strefie czasowej - początkowo twórcy Uniksa w ogóle o tym nie pomyśleli. Dopiero potem dodano informację, że czas uniksowy ustalany jest w strefie Uniwersalnego Czasu Koordynowanego, czyli UTC.
- 32 bity to nie tak dużo i czas 32-bitowy skończy się w 2038 roku. W lata 70. mogło się to wydawać odległą datą, ale dziś jest całkiem namacalna. Znam ludzi, którzy będą dłużej spłacać kredyty.
Problemów z datą uniksową jest więcej (np. brak liczenia sekund przestępnych), ale te dwie były najważniejsze. Z rzekomym „problemem roku 2038” poradziliśmy sobie łatwo - po prostu wszystkie współczesne systemy zapisują liczby całkowite w dacie jako 8 bajtów. Koniec czasu uniksowego 64-bitowego nastąpi więc o 15:30:08 UTC, 4 grudnia 292277026596 roku.
Świadomość określania punktu w czasie jako jednej liczby całkowitej jest wysoka wśród programistów i specjalistów IT. W 2009 roku, gdy Unix Time wynosił 1234567890 sekund, Google uczcił to nawet specjalnym doodlem, czyli obrazkiem logo. Natomiast wewnętrzny zapis dat czasami ujawnia się tak, jak we wspomnianym na wstępie błędzie na naszym serwerze. Wyzerowanie pola z datą (czyli ustawienie go na liczbę całkowitą 0) spowodowało, że kilka tekstów przeniosło się w czasie do 1 stycznia 1970 roku.
