Już gromadzę granaty gazu łzawiącego i wodę butelkowaną! : P
Kevin Cantu
Odpowiedzi:
17
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.
Dobry! Nie myślałem o tym przykładzie! Czego używa standard PKI jako składnia czasu w certyfikatach? Nigdy nie patrzyłem!
geoffc
@geoffc, Właściwie to był zastrzeżony format i miał swoją wewnętrzną strukturę daty / godziny, które same były wystarczająco duże, aby zmieścić daty po 2038 roku, ale używały funkcji GLIBC do konwersji daty / godziny. Jeśli dobrze pamiętam, mktimepołączenie po cichu kończyło się niepowodzeniem.
Alex B,
13
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
Mówiąc jak ktoś, kto pracował nad tym problemem, Y2K zawiodło z powodu dużej ilości pracy i planowania wcześniej. Postrzeganie wilgotnego kibica zostało wzmocnione przez wszystkie przesadzone skazania w mediach. Oczekuję, że od około 2035 r. Będzie dużo planowania i pracy, ale jeśli będziemy mieli szczęście, przegapimy zamieszanie w mediach.
David Thornley,
Pozdrowienia dla linka Mark.
boehj
9
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.
Największym problemem, jaki widzę, są formaty plików i pliki, ale zakres dat dla ext4 to 2514, vfat to 2107. Problem dotyczy reiserfs (2038).
Maciej Piechotka,
ReiserFS ma jeszcze inne problemy. Nadal uważam, że jest o wiele więcej ukrytych miejsc niż ludzie myślą o tym czasie w sklepie CTIME. Jest to naprawdę prosty i użyteczny format czasu. Oczywiście, niepodpisany CTIME nie ma problemu 2037. Myślę, że jest to przypadek znacznika czasu 2107.
geoffc
1
Myślisz o Apple HFS. FAT w ogóle nie używa time_t. Przechowuje rok, miesiąc i dzień jako pola w jednej wartości 16-bitowej: 5 bitów na dzień, 4 na miesiąc, pozostawiając 7 na rok. 2107 to 1980 (rok zerowy na ziemi FAT) + 2 ^ 7-1. Aby uzyskać więcej zabawy, FAT zapisuje porę dnia w ten sam sposób w innej 16-bitowej wartości, ale jeśli wykonasz matematykę, okaże się, że potrzebujesz 17 bitów, aby zapisać porę dnia w ten sposób. FAT rozwiązuje ten problem, tracąc na sekundę rozdzielczość; FAT nie może odróżnić zmian w odstępie krótszym niż 2 sekundy. Ach, Microsoft, jaki byłby nudny świat bez twoich niepotrzebnych niezgodności!
Warren Young,
8
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ę.
Próbowałem wersji 32-bitowej Ubuntu i pokazało to problemy 2038, ale uruchomienie 64-bitowej wersji Ubuntu nie wykazało żadnych oznak problemu 2038. Nie próbowałem żadnych innych Uniksów.
Jimmy Hedman
Tak, w większości wersji 32-bitowych zobaczysz problem, ale nie w wersji 64-bitowej. Możesz spodziewać się, że w 2038 r. Nie będziesz już mieć 32-bitowego systemu operacyjnego.
Promień
2
To śmieszne założenie. Nadal używamy 16 (a nawet 8 bitów) mikroprocesorów w dzisiejszym świecie, co oznacza, że 32-bitowe mikroprocesory magicznie znikną w przyszłości? Można śmiało powiedzieć, że nie wpłynie to na przeciętnego użytkownika, ale w skrajnych przypadkach może nadal stanowić problem.
Eli Frey,
Cóż - komputery 16-bitowe i 8-bitowe mogą 1. przenieść datę 0 (z 1970-01-01 na przykład 2010-01-01) - jednak złamałoby to niektóre konwencje API / ABI 2. rozszerzyło pole timera ( co może w niektórych przypadkach złamać „tylko” ABI).
Maciej Piechotka,
1
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).
Czy mógłbyś to rozwinąć, aby wyjaśnić, na czym dokładnie polega problem i jak na to zareagować?
Anthon
Problem dotyczy 32-bitowej liczby całkowitej używanej do obliczania czasu. Czas jest mierzony w sekundach, które upłynęły od 1 stycznia 1970 roku. Na przykład po jednym dniu licznik wyniesie 86400. Tak więc w 2038 roku ta wartość przepełni się, ponieważ będzie zawierała wartość większą niż liczba, którą można przechowywać w 32-bitowa liczba całkowita bez znaku. 64-bitowy system wykorzystujący 64 bity dla znacznika czasu nie będzie miał tego problemu, ponieważ będzie mógł pracować do 15:30:08 w niedzielę, 4 grudnia 292 277,026,596 (292 miliardów lat)
Rahul Kadukar
0
#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.
To nie jest „system” ani „system operacyjny”. Większość poprzednich 32-bitowych systemów operacyjnych (nawet 16-bitowych) może wykonywać matematykę 64-bitową. 64-bitowa głębia na poziomie systemu operacyjnego jest w zasadzie odniesieniem do modelu pamięci, a nie do umiejętności matematycznych. A czas dotyczy matematyki.
geoffc
Tak i nie. Prawdą jest, że 32-bitowy i 64-bitowy system operacyjny może wykonywać arytmetykę 64-bitową (można emulować dowolną arytmetykę). Jednak time_t(lub równoważny) w 32-bitowym systemie operacyjnym ma 32 bity, podczas gdy time_t(lub równoważny) w 64-bitowym systemie operacyjnym ma 64 bity. Myślałem, że to wystarczająco jasne, nawet z pewnym uproszczeniem.
Maciej Piechotka,
0
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.
Prawdopodobnie nikt (a właściwie praktycznie nikt) nie przechowuje obecnie takiego formatu (np. DCD lub ciąg znaków). Czas jest zwykle obsługiwany przez obiekty lub ints (więc tylko kod wyświetlania musiałby zostać zaktualizowany).
Maciej Piechotka,
Tak, dokładnie o to mi chodzi. Y2K skutecznie zniweczył pomysł reprezentowania dat jako ciągów o stałej długości.
Stephen Jazdzewski
@Stephen: Nie w świecie COBOL, ale na szczęście istnieje niewiele implementacji COBOL w systemach Unix / Linux.
David Thornley,
@David: Programy w języku COBOL były w większości problemami Y2K. Czy systemy Linux / Unix, z punktu widzenia użytkowników, miały kiedykolwiek problem z Y2K? Prosta odpowiedź na pierwotne pytanie brzmi: nie.
Stephen Jazdzewski
4
Plakat nie pyta o problem y2k; pytają o problem y2k38, który jest zupełnie inną bestią. Sprawdzić en.wikipedia.org/wiki/Y2K38 dla opisu.
Odpowiedzi:
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.
źródło
mktime
połączenie po cichu kończyło się niepowodzeniem.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
źródło
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.
źródło
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.
źródło
time_t
. Przechowuje rok, miesiąc i dzień jako pola w jednej wartości 16-bitowej: 5 bitów na dzień, 4 na miesiąc, pozostawiając 7 na rok. 2107 to 1980 (rok zerowy na ziemi FAT) + 2 ^ 7-1. Aby uzyskać więcej zabawy, FAT zapisuje porę dnia w ten sam sposób w innej 16-bitowej wartości, ale jeśli wykonasz matematykę, okaże się, że potrzebujesz 17 bitów, aby zapisać porę dnia w ten sposób. FAT rozwiązuje ten problem, tracąc na sekundę rozdzielczość; FAT nie może odróżnić zmian w odstępie krótszym niż 2 sekundy. Ach, Microsoft, jaki byłby nudny świat bez twoich niepotrzebnych niezgodności!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ę.
źródło
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).
źródło
Problemem będą nadal działające systemy 32-bitowe.
źródło
powinna wynosić 1 zamiast 9, ale ctime nie obsługuje większej daty:
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:
int
są 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)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.
źródło
time_t
(lub równoważny) w 32-bitowym systemie operacyjnym ma 32 bity, podczas gdytime_t
(lub równoważny) w 64-bitowym systemie operacyjnym ma 64 bity. Myślałem, że to wystarczająco jasne, nawet z pewnym uproszczeniem.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.
źródło
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 ...
źródło