Czym jest problem roku 2038?

Problem Roku 2000 jest obecnie rozumiany przez większość ludzi ze względu na dużą ilość uwagi, jaką poświęcono mu w mediach.

Większość programów napisanych w języku programowania C jest stosunkowo odporna na problem Y2K, ale cierpi z powodu problemu Roku 2038. Problem ten pojawia się, ponieważ większość programów w języku C używa biblioteki procedur zwanej standardową biblioteką czasu . Biblioteka ta ustanawia standardowy 4-bajtowy format do przechowywania wartości czasu, a także zapewnia szereg funkcji do konwersji, wyświetlania i obliczania wartości czasu.

Standardowy 4-bajtowy format zakłada, że początek czasu to 1 stycznia 1970 r., o godzinie 12:00:00. Wartość ta wynosi 0. Każda wartość czasu/daty jest wyrażona jako liczba sekund następujących po tej wartości zerowej. Tak więc wartość 919642718 to 919 642 718 sekund po godzinie 12:00:00 dnia 1 stycznia 1970 roku, czyli w niedzielę 21 lutego 1999 roku o godzinie 16:18:38 czasu pacyficznego (USA). Jest to wygodny format, ponieważ jeśli odejmiesz dwie dowolne wartości, otrzymasz liczbę sekund, która jest różnicą czasu między nimi. Następnie możesz użyć innych funkcji w bibliotece, aby określić, ile minut/godzin/dni/miesięcy/lat upłynęło pomiędzy tymi dwoma czasami.

Jeśli przeczytałeś Jak działają bity i bajty, wiesz, że podpisana 4-bajtowa liczba całkowita ma maksymalną wartość 2 147 483 647, i to właśnie stąd pochodzi problem roku 2038. Maksymalna wartość czasu, zanim zmieni się na wartość ujemną (i nieważną), wynosi 2 147 483 647, co przekłada się na 19 stycznia 2038 roku. W tym dniu wszystkie programy w C, które używają standardowej biblioteki czasu, zaczną mieć problemy z obliczaniem daty.

Problem ten jest na szczęście nieco łatwiejszy do naprawienia niż problem Y2K na mainframe’ach. Dobrze napisane programy mogą być po prostu przekompilowane z nową wersją biblioteki, która używa np. 8-bajtowych wartości dla formatu zapisu. Jest to możliwe, ponieważ biblioteka hermetyzuje całą działalność czasową za pomocą własnych typów i funkcji czasowych (w przeciwieństwie do większości programów mainframe’owych, które nie standaryzowały swoich formatów dat i obliczeń). Tak więc problem Roku 2038 nie powinien być prawie tak trudny do naprawienia, jak był problem Y2K.

Tutaj kilka interesujących linków: