Почему большинство методов java.util.Date устарели?

Question

Когда вы смотрите на javadoc класса java.util.Date, большинство методов устарели. Почему это было сделано?

Answer 1

Ну, по двум причинам. Это была очень плохая реализация концепции Dates and Times, и ее заменил класс Calendar.

Класс Calendar, хотя и улучшается, оставляет желать лучшего, поэтому для серьезных работ Дата/Время каждый рекомендует Joda-Time. Java 8 приносит новый java.time.* package, вдохновленный Joda-Time, определяемый JSR-310 и предназначенный для замены старых классов Date/Calendar.

Редактировать: В ответ на конкретный вопрос о том, почему реализация плоха, есть много причин. JavaDoc суммирует его следующим образом:

К сожалению, API для этих функций не поддается интернационализации.

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

Calendar имеет свои проблемы, но даже уже в JDK 1.1 было очевидно, что java.util.Date не собирался его разрезать. Несмотря на то, что Calendar является аргументом в пользу худшего API JDK, он попытался решить эту проблему до версии 7.

Answer 2

Они устарели, потому что дата была написана как можно быстрее в тот же день, когда они хотели вытолкнуть JDK из двери.

Получается, что даты и календари трудны. Таким образом, они создали класс Calendar, который гораздо больше думает, чтобы обрабатывать жесткие части работы с календарями.

Они устарели методы Date и делегированы в Календарь, потому что они не хотят изменять поведение существующих методов Date и, возможно, нарушают существующие приложения.

Answer 3

• Date изменчиво
• Date не имеет поддержки часовых поясов

Последние привели к нему на смену Calendar. И первое, в сочетании с использованием простотой в, приводят как к заменяются Joda-Time/JSR-310 (java.time.* package)

Answer 4

Я не знаю официальную причину, почему это было устаревшим, но, насколько я могу сказать GregorianCalendar и Joda-Time операции поддержки по датам, что означает, что вы можете добавить, например, день до даты и соответствующим образом обновить свой месяц и год.

Например, скажем, вы хотите вычислить день после текущей даты и сегодня - 31 мая; с java.util.Date, у вас только есть getDays() +1, который возвращает 32, и вам нужно справиться с тем, что текущий месяц не имеет 32 дней; с GregorianCalendar или Joda.time, добавив, что день до 31 мая приведет к объекту, который будет показан 1 июня, скрывая сложность с вашего зрения.

Answer 5

Вот хороший ответ прямо из Oracle: http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html

Давняя пугало разработчиков Java была неадекватная поддержка даты и времени использования случаев обычных разработчиков.

Например, существующие классы (например, java.util.Date и SimpleDateFormatter) не являются потокобезопасными, что приводит к потенциальным проблемам параллелизма для пользователей, а не к среднему разработчику, с которым придется рассчитывать при написании кода обработки даты.

Некоторые из классов даты и времени также демонстрируют довольно плохой дизайн API. Например, годы в java.util.Date начинаются с 1900 года, месяцы начинаются с 1, а дни начинаются с 0 - не очень интуитивно.

... java.util.Date представляет собой мгновение на временной шкале - обертка вокруг количества миллисекунд с эпохи UNIX, но если вы вызываете toString(), результат подсказывает, что у нее есть часовой пояс, что вызывает путаницу среди Разработчики.