У меня есть веб-приложение, которое заказывает материал, используя временную метку, которая просто длинная. Бэкэнд веб-приложений написан в Java, поэтому я использую:
long timestamp = System.currentTimeMillis();
какой год (примерно) это провалится? Я имею в виду, что в какой-то момент диапазон длинного переполнения, не так ли? Мы все можем быть давно умершими, но мне просто интересно. Будет ли это похоже на y2k снова? Что я могу сделать, чтобы подготовиться к этому? Смешно, я знаю, просто любопытно!
Спасибо
Переполнение будет
System.out.println(new Date(Long.MAX_VALUE));
который печатает
Sun Aug 17 03:12:55 GMT-04:00 292278994
Таким образом, после чуть более 292 миллионов лет. Я бы сказал, есть много времени, чтобы изобрести решение в то же время. Честно говоря, я не ожидаю, что человечество сможет выжить. Мы существуем всего несколько секунд по сравнению с возрастом мира в часовом масштабе, и это не займет много времени.
Попробуйте запустить этот код:
System.out.println(new Date(Long.MAX_VALUE));
Что печатает что-то подобное в зависимости от вашей локали:
Sun Aug 17 17:12:55 EST 292278994
Очень долго в будущем, поэтому не нужно беспокоиться о переполнении.
"Что я могу сделать, чтобы подготовиться к этому?"
Хорошо, вы могли бы украсить свой гроб с помощью самых последних и самых продаваемых игрушек для IT/geek. Но почему-то я думаю, что они будут немного "устаревшими" в 292 278 994 году нашей эры. К тому времени вам будет очень скучно.
Помните, у вас будет достаточно времени, чтобы переписать ОС с нуля, чтобы использовать 128-битные часы. Это похоже на забавный проект, чтобы избавиться от времени.: -)
Кажется маловероятным, что ваше веб-приложение все равно будет на солнце 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 ) ;
}
Если вы живы, когда запускается какое-либо из этих утверждений, вы, возможно, можете заряжать своих клиентов большими долларами для фиксации системных часов или изменения утверждения (в зависимости от ситуации).
Максимальное значение Java long равно 2^63 - 1, и если вы конвертируете столько миллисекунд в практические единицы времени, вы обнаружите, что счетчик будет переполняться примерно через 290 миллионов лет. Поэтому не беспокойтесь об этом;-) Если кто-нибудь еще будет запускать компьютеры, я уверен, что к этому времени они перейдут на 128-битные счетчики времени (или выбрали новую эпоху).
Ошибка в этих ответах предполагает, что система, в которой вы работаете, составляет 64 бит и возвращает с 64-разрядного представления миллисов с 1970 года. Linux использует 32-битное представление, а переполнение - в 2038 году.
См. Проблема 2038 года для справки