Problem roku 2038 lub błędów w roku 2038 (w Kanadzie), znany również jako Y2038 , jest bug komputer podobny do roku 2000 błędów , które mogłyby zakłócić działanie wielu systemów IT19 stycznia 2038o 3 h 14 min 8 s , czas uniwersalny . Będą wtedy wyświetlać13 grudnia 1901i 20 godz. 45 min. 52 s .
Ten błąd potencjalnie dotyczy wszystkich systemów operacyjnych i programów, które używają 32-bitowej reprezentacji daty . Wpływa na formaty plików (takie jak ZIP ), systemy plików (takie jak system plików FAT używany na większości dysków USB i kart flash) oraz systemy operacyjne na wszystkich poziomach (od jądra przez system do obsługi w językach programowania ), a nawet sam zegar czasu rzeczywistego .
Problem dotyczy oprogramowania, które używa reprezentacji czasu POSIX , gdzie czas jest reprezentowany jako liczba sekund, które upłynęły od1 st styczeń 1970o północy ( 0 godzin ) czasu uniwersalnego . Na komputerach 32-bitowych, najbardziej dotknięte systemy operacyjne reprezentować ten numer jako 32-bitowe podpisane liczb całkowitych, co ogranicza liczbę sekund do 231 - 1, lub 2147483 647 sekund (01111111 11111111 11111111 11111111 w binarnym ). Ta maksymalna liczba zostanie osiągnięta w dniu19 stycznia 2038po 3 godz. 14 min 7 s (czas uniwersalny). W następnej sekundzie reprezentacja czasu „zapętli się” (10000000 00000000 00000000 00000000 w formacie binarnym) i będzie reprezentować -2 147 483 648 w uzupełnieniu do dwóch , a zatem komputer wyświetli datę13 grudnia 1901.
Zagrożone oprogramowanie jest bardzo liczne, ponieważ standard POSIX , inspirowany systemami UNIX , był używany w wielu programach napisanych w języku C dla wielu systemów operacyjnych. W systemach typu Unix reprezentujących czas za pomocą 32-bitowej liczby całkowitej bez znaku (zgodnej ze standardem POSIX), termin upływa w 2106, a nie w 2038. Te systemy operacyjne stanowią jednak mniejszość. Przełączenie na stemplem czasowym od 64 bitów wprowadzi nowy termin leżącego niedziela4 grudnia 292277026596ok. BC co 15 h 30 min 8 s (około 21 razy wieku od świata ), a zatem rozwiązanie problemu, ponieważ 64 bitów by umożliwić jego push ograniczenia do 2 63 - 1 s.
W dziedzinie aplikacji problem ujawnił się już w 2010 roku, a rok 2000 został ujawniony już w latach 80. na osiach czasowych planów długoterminowych ( od tego czasu arkusze kalkulacyjne używały albo dat ruchomych, albo formatu długiego) .
Nie ma jednego, pojedynczego rozwiązania tego problemu, ponieważ 32-bitowe znaczniki czasu są również obecne w kilku bieżących formatach plików (np. w formacie ZIP ). Zmiana reprezentacji w komputerach uniemożliwiłaby działanie programów wykorzystujących obecną równoważność między reprezentacją wewnętrzną a formatem pliku. W związku z tym trzeba będzie dużo pracy „za kulisami”, aby prawie nic nie pojawiło się na powierzchni, co miało już miejsce, gdy zbliżał się rok 2000.
Wiele obecnie używanych struktur danych ma reprezentacje czasu w formacie 32-bitowym , w szczególności dla najbardziej znanych:
Przykłady systemów używających 32-bitowych formatów czasu:
Wszystkie systemy operacyjne korzystające z 64-bitowego jądra Linuksa są odporne.
Wersja 3.17 jądra Linux wykorzystuje wewnętrzną reprezentację dat na 64 bitach, która przygotowuje inne niezbędne adaptacje, na poziomie standardowych bibliotek C, a następnie aplikacji.
AndroidMarshmallow wersja 6.0 z Android oparty na Linux kernel 3.10 nie zawiera żadnych poprawek.
OknaW Visual C 8 czas jest domyślnie zakodowany na 64 bitach.
W Visual C 7.1 deweloper musi jawnie używać czasu 64-bitowego.
Daty są obecnie uważane za niepodpisane, co wydłuża ich żywotność o 68 lat.
Następujące systemy kodują swoje daty w 64 bitach:
Network Time Protocol (NTP) używa daty bazowej na1 st styczeń 1900zakodowane na 64 bitach, z których 32 bity reprezentują sekundy. Nie podlega więc błędowi roku 2038, ale błędowi roku 2036.
NTPv4 używa pól „numer ery” i „początek ery”, które omijają błąd.
Kolejne wersje protokołu będą używać dat zakodowanych na 128 bitach, z czego 64 bity będą reprezentować sekundy.
Nie ma jednego uniwersalnego rozwiązania problemów, które pojawią się w wyniku błędu roku 2038. Jakakolwiek zmiana w definicji typu zmiennej używanej do oznaczenia czasu time_tspowodowałaby problemy ze zgodnością kodu we wszystkich z nich. aplikacje, w których reprezentacja daty i godziny zależy od systemu zaprojektowanego do pracy z 32-bitową liczbą całkowitą ze znakiem. Na przykład zmiana time_tna 32-bitową liczbę całkowitą bez znaku, która pozwoliłaby na używanie systemów do roku 2106, spowodowałaby komplikacje dla programów, które manipulują danymi, których daty poprzedzają rok 1970, ponieważ takie daty byłyby reprezentowane przez ujemne liczby całkowite. Ponadto rozszerzenie zmiennej time_tdo 64-bitowej liczby całkowitej w obecnie używanych systemach spowodowałoby niekompatybilne zmiany w organizacji struktur i binarnym interfejsie niektórych funkcji.
Najprostszym proponowanym rozwiązaniem jest zmiana systemu z 32 bitów na 64 bity . Rzeczywiście, obecnie większość systemów komputerowych zaprojektowanych z myślą o sprzęcie 64-bitowym już obsługuje zmienne time_t64-bitowe.