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

Ответ 1

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

Класс Calendar, хотя и улучшается, оставляет желать лучшего, поэтому для серьезной работы Date/Time каждый рекомендует 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 он попытается обратиться к нему.

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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