Зачем программисту Java заботиться о ошибке 2038 года?

Ответ 1

Почему вы думаете, что это так? Класс Java Date хранит 64-разрядный long (не 32-разрядный, как у Y2K38). Он также хранит миллисекунды, что уменьшает диапазон, но только незначительно (эквивалентно ~ 10 бит).

В Java у нас есть ошибка 292278994 года.

Ответ 2

Я не верю, что это повлияет на класс Java Date, как на программиста. Он уже использует 64-битные значения. Я вижу, что это проблема, если вы используете хранилище данных, которое все еще использует 32-битные значения. Я не ожидаю увидеть слишком много 32-разрядных ОС за 27 лет.

Ответ 3

Java и время не ограничены только классом Date.

Откуда берутся даты/время? Часто из System.currentTimeMillis, который собственный метод. Обычно он не реализован на Java. Тип возврата длинный, но это мало значит, поскольку собственный метод может возвращать любое значение, которое просто вписывается в длинный.

Все будет зависеть от ОС и ее реализации JRE.

Опираться на присутствие 64-битных систем может быть наивным, поскольку, видимо, существует много встроенных систем, которые являются 32-разрядными и будут по-прежнему оставаться.

В общем, Java подвергается проблеме 2038.

Ответ 4

Это, вероятно, осталось от старых дней C, когда типы данных даты свернули в 2038 году. Возможно, это проблема с некоторыми действительно старыми приложениями, но не для Java. Йон.

Ответ 5

На самом деле это не ответ. Но некоторые должности получили все правильно. Java совместим с 2038, но не совместим с 10000 (если вы вставляете длинный конструктор Date, который представляет что-то после 9999, он не будет работать и возвращает некоторое странное число), но да, 2147483648 определенно не является максимально допустимым значением в Java Date класс.