Co zrobić, aby przygotować się do 2038 roku?
Chciałbym myśleć, że część oprogramowania, które dziś piszę, będzie używana za 30 lat. Ale jestem również świadomy, że wiele z nich opiera się na uniksowej tradycji ujawniania czasu jako liczby sekund od 1970 roku.
#include <stdio.h>
#include <time.h>
#include <limits.h>
void print(time_t rt) {
struct tm * t = gmtime(&rt);
puts(asctime(t));
}
int main() {
print(0);
print(time(0));
print(LONG_MAX);
print(LONG_MAX+1);
}
Wyniki wykonania w:
- Czw Sty 1 00:00:00 1970
- Sob Sie 30 18:37:08 2008
- WT Sty 19 03:14:07 2038
- PT Gru 13 20:45:52 1901
Funkcje ctime(), gmtime() i localtime () przyjmują jako argument wartość czasu reprezentującą czas w sekundach od epoki(00:00:00 UTC, 1 stycznia 1970; zobacz time (3)).
Zastanawiam się, czy jest coś proaktywnego do zrobienia w tej dziedzinie jako programista, czy mamy ufać, że wszystkie systemy oprogramowania (aka systemy operacyjne) będą w jakiś sposób magicznie zmodernizowane w przyszłości?
Update wydaje się, że rzeczywiście 64-bitowe systemy są bezpieczne od to:
import java.util.*;
class TimeTest {
public static void main(String[] args) {
print(0);
print(System.currentTimeMillis());
print(Long.MAX_VALUE);
print(Long.MAX_VALUE + 1);
}
static void print(long l) {
System.out.println(new Date(l));
}
}
- śro Gru 31 16: 00: 00 PST 1969
- Sob Sie 30 12:02:40 PDT 2008
- Sob Sie 16 23:12:55 PST 292278994
- nie Gru 02 08:47: 04 PST 292269055
10 answers
Napisałem przenośny zamiennik na czas.h (obecnie tylko localtime(), gmtime(), mktime() i timegm ()), który używa czasu 64 bitowego nawet na maszynach 32 bitowych. Ma być zrzucony do projektów C jako zamiennik na czas.h. jest on używany w Perlu i zamierzam naprawić problemy Ruby i Pythona 2038 z nim również. Daje to Bezpieczny zakres + / - 292 milionów lat.
Możesz znaleźć kod w projekcie y2038 . Wszelkie pytania prosimy kierować do tracker issue tracker .
Jeśli chodzi o "to nie będzie problemem przez następne 29 lat", zapoznaj się z tą listą standardowych odpowiedzi na to. Krótko mówiąc, rzeczy dzieją się w przyszłości i czasami trzeba wiedzieć, kiedy. Mam też prezentację na temat problemu, co nie jest rozwiązaniem, a co jest . I nie zapominaj, że wiele systemów czasowych nie obsługuje dat sprzed 1970 roku. Rzeczy miały miejsce przed 1970 rokiem, czasami trzeba wiedzieć kiedy.Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-02-11 23:20:07
Zawsze możesz zaimplementować RFC 2550 i być bezpiecznym NA ZAWSZE; -)
Znany wszechświat ma skończoną przeszłość i przyszłość. Obecny wiek wszechświat jest szacowany w [Zebu] jako pomiędzy 10 ** 10 a 2 * 10 ** 10 lat. Śmierć wszechświata szacuje się w [ ... ] w 10 ** 11 - lat i w [ ... ] jako występujące w 10 * * 12 lat dla zamkniętego wszechświata (big crunch) lub 10 * * 14 lat dla otwarty wszechświat (the heat death of wszechświata).
Programy zgodne z Y10K mogą wybrać ograniczenie zakresu dat, które wsparcie dla osób zgodnych z oczekiwanym życiem wszechświata. Systemy zgodne z Y10K muszą akceptować daty Y10K od 10 * * 12 lat w przeszłość do 10 * * 20 lat w przyszłość. Systemy zgodne z Y10K Powinny przyjmować daty co najmniej 10 * * 29 lat w przeszłości i przyszłość.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-10-25 21:39:42
Visual Studio zostało przeniesione na 64-bitową reprezentację time_t w Visual Studio 2005 (nadal pozostawiając _time32_t dla kompatybilności wstecznej).
Tak długo, jak jesteś ostrożny, aby zawsze pisać kod pod względem time_t i nie zakładać nic o rozmiarze, to jak wskazuje sysrqb problem zostanie rozwiązany przez kompilator.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-08-30 18:49:06
Myślę, że powinniśmy zostawić pluskwę w środku. Następnie około 2036 możemy zacząć sprzedawać doradztwo za duże sumy pieniędzy, aby przetestować wszystko. W końcu nie w ten sposób udało nam się pomyślnie przejść rollover z lat 1999-2000.
Ja tylko żartuję!
Siedziałem w banku w Londynie w 1999 roku i byłem bardzo zaskoczony, gdy zobaczyłem konsultanta, który zaczął testować ekspres do kawy. Myślę, że gdybyśmy się czegoś nauczyli z tego fiaska, to było to, że zdecydowana większość oprogramowania będzie po prostu działać i większość reszta nie spowoduje stopienia, jeśli się nie powiedzie i w razie potrzeby może być naprawiona po zdarzeniu. W związku z tym nie podejmowałbym żadnych specjalnych środków ostrożności, dopóki nie zbliżyłbym się do tego czasu.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-03-25 17:42:44
Biorąc pod uwagę mój wiek, myślę, że powinienem zapłacić dużo do mojej emerytury i zapłacić wszystkie moje działy, więc ktoś inny będzie musiał dopasować oprogramowanie!
Przepraszam, jeśli myślisz o" aktualnej wartości netto " dowolnego oprogramowania, które piszesz dzisiaj, nie ma to wpływu na to, co oprogramowanie robi w 2038 roku. "Zwrot z inwestycji" dłuższy niż kilka lat jest rzadkością w przypadku każdego projektu oprogramowania, więc zarabiasz dużo więcej pieniędzy dla swojego pracodawcy, dzięki szybszemu dostarczaniu oprogramowania, zamiast myśleć tak daleko w przyszłość.
Jedynym powszechnym wyjątkiem jest oprogramowanie, które musi przewidywać przyszłość, 2038 jest już problemem dla Systemów notowań hipotecznych.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-10-03 16:33:10
Zachowaj dobrą dokumentację i dołącz opis swoich zależności czasowych. Nie sądzę, aby Wiele osób zastanawiało się, jak trudne może być to przejście, na przykład ciasteczka HTTP zostaną złamane w tym dniu.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-10-25 21:15:48
Ukryj się, bo nadchodzi apokalipsa.Co zrobić, aby przygotować się do 2038 roku?
Ale poważnie, mam nadzieję, że Kompilatory (lub osoby, które je piszą, aby być precyzyjnym) poradzą sobie z tym. Mają prawie 30 lat. Mam nadzieję,że to wystarczy.
W którym momencie zaczynamy przygotowania do Y10K? Czy jacyś producenci sprzętu / laboratoria badawcze zastanawiali się nad najłatwiejszym sposobem przejścia na jakąkolwiek nową technologię będziemy musieli z tego powodu mieć?
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-10-04 13:40:45
Pracuję w embedded i pomyślałem, że zamieszczę tutaj nasze rozwiązanie. Nasze systemy są na 32 bitach, a to, co teraz sprzedajemy, ma gwarancję 30 lat, co oznacza, że napotkają błąd roku 2038. Modernizacja w przyszłości nie była rozwiązaniem.
Aby to naprawić, ustawiamy datę jądra 28 lat wcześniej niż bieżąca data. To nie jest przypadkowe przesunięcie, 28 lat to excatly czas, który zajmie dni tygodnia, aby ponownie dopasować. Na przykład piszę to w czwartek i następnym razem 7 marca będzie czwartek jest za 28 lat.
Ponadto wszystkie aplikacje, które wchodzą w interakcję z datami w naszych systemach, zamienią datę systemową (time_t) na niestandardową time64_t i zastosują przesunięcie 28 lat do właściwej daty.
Stworzyliśmy własną bibliotekę, aby się tym zająć. Kod, którego używamy, opiera się na tym: https://github.com/android/platform_bionic
Dzięki temu rozwiązaniu możesz łatwo kupić sobie dodatkowe 28 lat.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-03-07 20:09:06
Do 2038 roku biblioteki czasu powinny używać 64-bitowych liczb całkowitych, więc nie będzie to tak wielka sprawa (w przypadku oprogramowania, które nie jest całkowicie pozbawione konserwacji).
Programy COBOL mogą być fajne.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-08-30 18:45:45
Operatywne słowo to "powinien".
Jeśli chcesz zapewnić przyszłość, możesz skonstruować własną klasę date/time I użyć jej, ale zrobiłbym to tylko wtedy, jeśli uważasz, że to, co piszesz, zostanie użyte NA legacy OS '
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-08-30 18:47:16