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

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

long timestamp = System.currentTimeMillis();

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

Спасибо

Ответ 1

Переполнение будет

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

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

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

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

Ответ 2

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

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

Что печатает что-то подобное в зависимости от вашей локали:

Sun Aug 17 17:12:55 EST 292278994

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

Ответ 3

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

Хорошо, вы могли бы украсить свой гроб с помощью самых последних и самых продаваемых игрушек для IT/geek. Но почему-то я думаю, что они будут немного "устаревшими" в 292 278 994 году нашей эры. К тому времени вам будет очень скучно.

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

Ответ 4

Кажется маловероятным, что ваше веб-приложение все равно будет на солнце 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 ) ;
}

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

Ответ 5

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

Ответ 6

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

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