Problem z roku 2038 [zamknięty]

Jakie jest prawdopodobieństwo, że problem roku 2038 będzie bardzo problematyczny?

Napotkałem ten problem we wbudowanym systemie Linux, który musiał obsługiwać daty po 2038 r. W niektórych długoterminowych certyfikatach kryptograficznych, więc powiedziałbym, że prawdopodobieństwo tego zależy od domeny aplikacji.

Chociaż większość systemów powinna być gotowa na długo przed 2038 r., Jeśli dzisiaj będziesz obliczać daty w dalekiej przyszłości, możesz mieć problem.

Myślę, że będzie to poważny problem, o wiele bardziej szkodliwy niż problemy Y2K z 1999/2000, ponieważ kod, którego dotyczy problem, jest ogólnie niższego poziomu (to CTIME), dlatego trudniej jest znaleźć miejsca, w których czas jest przechowywany w ten sposób.

Aby jeszcze bardziej skomplikować sprawę, fakt, że Y2K był postrzegany jako wilgotny squib, utrudni zwrócenie uwagi na problem w przygotowaniu do wydarzenia.

Referencje kulturowe:

Cory Doctorow wypróbował nowy model do zamawiania / publikowania krótkich opowiadań na otwartych licencjach, a ja zasugerowałem motyw z 2038 r. Dla jednego z nich, który znakomicie zrobił w Epoch: http://craphound.com/?p=2337

Kilka lat temu pojawiły się już doniesienia o problemach w obszarach takich jak programy hipoteczne przeprowadzające obliczenia na pożyczki 30-letnie: 2008 + 30 = 2038.

64-bitowy system operacyjny jest ostatecznie nieistotny dla problemu 2037. (CTIME kończy się bliżej 2037 niż 2038).

Pytanie nie dotyczy głębi bitowej systemu operacyjnego, a raczej sposobu przechowywania czasu przez system operacyjny. Lub w jaki sposób kolumna bazy danych wybiera czas do przechowywania. Lub w jaki sposób ten atrybut składni czasu usług katalogowych przechowuje czas na zapleczu.

Jest to o wiele większy problem, niż ludzie myślą, ponieważ tak powszechne i powszechne jest używanie 32-bitowych liczników czasu.

Każde wystąpienie, które przechowuje czas, musi zostać ponownie sprawdzone, wszystkie API zaktualizowane, a także wszystkie narzędzia, które go używają, również zaktualizowane.

Warstwy abstrakcji, które pozwalają ustawić czas w formacie czasu czytelnym dla człowieka, zamiast surowych danych zapisanych, ułatwiają, ale to tylko jeden przypadek.

Podejrzewam, że będzie to znacznie większa sprawa niż myśli większość ludzi.

To jest moja opinia, ale ten problem wynika z 32-bitowego problemu z licznikiem, dziś większość systemów operacyjnych jest aktualizowana, aby obsługiwać czas na 64-bitowych (przynajmniej na 64-bitowych komputerach), więc myślę, że cały system operacyjny i oprogramowanie będą gotowe przez długi czas czas przed 2038 r., powiedzmy 2020. Więc możesz mieć problemy tylko wtedy, gdy w 2038 r. będziesz nadal uruchamiał oprogramowanie od 2020
r. Prawdopodobnie nie będzie to problemem prawie we wszystkich przypadkach. Mam nadzieję.

Nie taka wielka sprawa.

Podczas pierwszego blitzu Y2K, w którym dostawcy oprogramowania i sprzętu musieli certyfikować swoje produkty jako „zgodne z Y2K”, aby je sprzedać (pamiętam, że kable sieciowe na PC Connection mają certyfikat zgodności z Y2K) wiele firm przeprowadziło szczegółowe audyty wszystkiego , ustawiając zegary w przyszłości i testując.

W tamtym czasie, ponieważ koszt testowania był tak wysoki, prawie zawsze testowali z kilkoma datami, takimi jak 1/1/99 (niektórzy programiści mogli użyć 99 jako wartownika), 12/31/99, 1/1 / 00, skok z 2000 r., 1/19/38 i wiele innych. Zobacz tutaj nużącą listę.

Dlatego uważam, że każde ważne oprogramowanie, które istniało w 1999 r., Prawdopodobnie nie będzie zawierało 2038 błędów, ale nowe oprogramowanie napisane od tego czasu przez nieświadomych programistów. Po tym, jak cały programista z klęską Y2K na ogół stał się bardziej świadomy problemów z kodowaniem daty, więc jest mało prawdopodobne, aby miał tak duży wpływ jak Y2K (co samo w sobie było czymś w rodzaju antylimatyzacji).

Problemem będą nadal działające systemy 32-bitowe.

#include <time.h>
#include <stdio.h>

int main() {
  time_t t = (time_t)(1L << (sizeof(time_t)*8 - 9));
  printf("%d\n", sizeof(time_t));
}

powinna wynosić 1 zamiast 9, ale ctime nie obsługuje większej daty:

8 - Sun Jun 13 07:26:08 1141709097

Mój system (oczywiście 64-bitowy) może działać nawet o 1 milion lat dłużej. Rozwiązaniem jest aktualizacja systemów do 64 bitów.

Problem polega na tym, że programy mogą tego nie obsłużyć. Szczególnie stary, odpowiedni i nie utrzymany. Twórcy są przyzwyczajeni do następujących faktów:

• intsą 32-bitowe (w rzeczywistości są zachowane jako 32-bitowe między innymi w systemach 64-bitowych, ponieważ założono, że zawsze są 32-bitowe)
• Większość typów (takich jak time_t) można bezpiecznie rzucićint

W popularnym oprogramowaniu FLOSS obie rzeczy prawdopodobnie nie przejdą recenzji „wielu oczu”. Od mniej popularnych i proporcjonalnych zależy w dużej mierze od autora.

Wydaje mi się, że w wolnym * nix świecie 2038 zostanie „niezauważony”, podczas gdy spodziewam się problemów na platformach „propertarnych” (tj. Tych z dużą liczbą programów własnościowych) - szczególnie, jeśli niektóre kluczowe elementy nie zostaną utrzymane.

Jeśli jest to coś w rodzaju Y2K, niektóre osoby zostały już dotknięte problemem i zmieniają oprogramowanie, ale większość programistów zignoruje to do pewnego czasu w latach 30. XX wieku, prawdopodobnie około 2035 r., W którym to momencie będzie dużo pracy, a każdy będzie wystarczająco duży znajomość K&R C i jeszcze nie dość starcza, nagle będzie w stanie zawrzeć umowę na duże pieniądze. Rzeczywiste przejście pokaże wiele rzeczy, które nie zostały jeszcze zrobione, prawdopodobnie nie wszystkie tak ważne.

Problemem Y2K były dwa czartery reprezentujące rok zamiast czterech.

Wiele systemów nie było w stanie odróżnić 2000 r. Od 1900 r., Ponieważ zapisały tylko „00”.

Prawie wszystkie systemy albo używają teraz 4 znaków do przechowywania roku, albo używają jakiejś biblioteki.

Niech wszyscy zamiast tego martwią się o rok 10000 (Y10K). Z wyjątkiem twórców systemów operacyjnych i bibliotek ...