Когда System.currentTimeMillis () переполнится?

Question

У меня есть веб-приложение, которое заказывает вещи, используя временную метку, которая является длинной. Бэкэнд моего веб-приложения написан на Java, поэтому я использую:

long timestamp = System.currentTimeMillis();

в каком году (приблизительно) это не удастся? Я имею в виду, в какой-то момент, диапазон длинных будет переполнен, верно? Возможно, мы все давно умерли, но мне просто любопытно. Будет ли это снова как y2k? Что я могу сделать, чтобы подготовиться к этому? Смешно, я знаю, просто любопытно!

Спасибо

Answer 1

Переполнится при

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

который печатает

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

Таким образом, спустя чуть более 292 миллионов лет. Я бы сказал, что у нас есть много времени, чтобы изобрести решение. Честно говоря, я не ожидаю, что человечество переживет это. Мы существуем всего несколько секунд по сравнению с возрастом мира в часовом масштабе, и это не займет много времени.

Answer 2

Попробуйте запустить этот код:

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

Что печатает что-то вроде этого в зависимости от вашей локали:

Sun Aug 17 17:12:55 EST 292278994

Очень долго в будущем, поэтому не нужно беспокоиться о переполнении.

Answer 3

Кажется маловероятным, что ваше веб-приложение все еще будет работать в воскресенье 17 августа 17:12:55 EST 292278994 (по подсчетам других).Еще более маловероятно, что вы все равно будете нести ответственность за веб-приложение.(Если вы по-прежнему несете ответственность за это, вам, вероятно, в будущем будут платить по более высокой ставке, поэтому позвольте ему сейчас понизиться и собрать большие деньги позже:)

Это намного, гораздо более вероятно, чтосистемные часы неправильно установлены на какое-то странное значение.Вы можете подготовиться к этому сравнительно легко - псевдокод ниже

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 ) ;
}

Если вы живы, когда срабатывает любое из этих утверждений, то вы, вероятно, можете взимать с клиентов большие деньги за то, чтобы либо исправить системные часы, либо изменитьутверждение (при необходимости).

Answer 4

"Что я могу сделать, чтобы подготовиться к этому?"

Ну, вы можете снабдить свой гроб новейшими и лучшими игрушками для ИТ-специалистов. Но почему-то я думаю, что они будут немного "устаревшими" в 292 278 994 годах нашей эры. И вам будет довольно скучно с ними к тому времени.

Имейте в виду, у вас будет достаточно времени, чтобы переписать ОС с нуля, чтобы использовать 128-битные часы. Это звучит как забавный проект, чтобы убить время. : -)

Answer 5

Максимальное значение Java long равно 2^63 - 1, и если вы преобразуете столько миллисекунд в практические единицы времени, вы обнаружите, что счетчик переполнится примерно через 290 миллионов лет. Так что не беспокойтесь об этом ;-) Если кто-нибудь еще поработает с компьютерами, я уверен, что к тому времени они переключатся на 128-битные счетчики времени (или выбрали новую эпоху).

Answer 6

Ошибка в этих ответах заключается в том, что используемая вами система является 64-битной и с 1970 года возвращает 64-битное представление в миллисекундах. Linux использует 32-битное представление, а переполнение - в 2038 году.

См. Проблема 2038 года для справки