Kiedy nastąpi przepełnienie System.currentTimeMillis()?

Question

Mam aplikację internetową, która zamawia rzeczy za pomocą znacznika czasu, który jest po prostu długi. Mój backend aplikacji webowej jest napisany w języku Java, więc używam:

long timestamp = System.currentTimeMillis(); 

w jakim roku (w przybliżeniu) to się nie uda? Chodzi mi o to, że w pewnym momencie zakres długości będzie się przepełniał, prawda? Wszyscy możemy od dawna nie żyć, ale jestem po prostu ciekawy. Czy znowu będzie jak y2k? Co mogę zrobić, aby się do tego przygotować? Śmieszne, wiem, po prostu ciekawi!

Dzięki

Answer 1

To będzie przelewać na

System.out.println(new Date(Long.MAX_VALUE)); 

która drukuje

Sun Aug 17 03:12:55 GMT-04:00 292278994 

to więc po nieco ponad 292 milionów lat. Powiedziałbym, że istnieje czas na wymyślenie rozwiązania w międzyczasie. Szczerze mówiąc, nie oczekuję, że ludzkość przetrwa to. Istnieje tylko kilka sekund w porównaniu do age of the world w skali godzin i nie zajmie to dużo czasu.

Answer 2

Maksymalna wartość Java long jest 2^63 - 1, a jeśli przekonwertować wiele milisekund do praktycznych jednostkach czasu, można zauważyć, że licznik będzie przelewać się około 290 milionów lat. Więc nie martw się o to ;-) Jeśli ktokolwiek jest nadal w pobliżu, aby uruchomić komputery, jestem pewien, że do tego czasu przełączyły się na 128-bitowe liczniki czasu (lub wybrały nową epokę).

Answer 3

Spróbuj uruchomić ten kod:

System.out.println(new Date(Long.MAX_VALUE)); 

która drukuje coś takiego w zależności od lokalizacji:

Sun Aug 17 17:12:55 EST 292278994 

Bardzo długo w przyszłości, więc nie trzeba się martwić o przepełnienie.

Answer 4

"Co mogę zrobić, aby się do tego przygotować?"

Cóż, możesz mieć trumnę wyposażyć w najnowsze i najlepsze zabawki IT/geek. Ale jakoś myślę, że będą nieco "przestarzałe" w 292 278 994 AD. A do tego czasu będziesz się nimi nudzić.

Pamiętaj, że będziesz mieć dość czasu na przepisanie systemu operacyjnego od zera, aby użyć zegara 128-bitowego. To brzmi jak zabawny projekt, który zabija czas. :-)

Answer 5

Wygląda na to, że twoja aplikacja internetowa nadal będzie dostępna w dniu 17 sierpnia 17:12:55 EST 292278994 (zgodnie z obliczeniami innych użytkowników). Wydaje się jeszcze mniej prawdopodobne, że nadal będziesz odpowiedzialny za aplikację internetową. (Jeśli nadal jesteś za to odpowiedzialny, prawdopodobnie otrzymasz wyższą stawkę w przyszłości, więc pozwól, że ześlizgnie się na chwilę i zbieraj duże pieniądze później :)

Jest o wiele bardziej prawdopodobne, że system Zegar jest ustawiony niepoprawnie na jakąś dziwaczną wartość.Można przygotować się do tego stosunkowo łatwo - Pseudokod poniżej

long reasonableDate () 
{ 
    long timestamp = System.currentTimeMillis(); 
    assert timestamp after 2010AD : "We developed this web app in 2010. Maybe the clock is off." ; 
    assert timestamp before 10000AD : "We don't anticipate this web app will still be in operation in 10000AD. Maybe the clock is off." ; 
    return (timestamp) ; 
} 

Jeśli są żywe po wyzwoleniu któregokolwiek z tych twierdzeń, to prawdopodobnie można obciążyć swoich klientów duże pieniądze za bądź ustalenie zegara systemowego lub zmianę twierdzenie (w razie potrzeby).

Answer 6

Błąd w tych odpowiedzi jest zakładając, że system używasz jest 64 bit i zwraca reprezentację 64 bitową milisekundach od 1970 roku Linux wykorzystuje 32-bitową reprezentację i przepełnienie w 2038.

Zobacz Year 2038 problem dla odniesienia