Почему «новая дата (int year, int month, int day)» устарела?

Question

Мое приложение, которое я недавно унаследовал, является ПОЛНЫМ предупреждением об устаревании конструктора:

Date d = new Date(int year, int month, int day)

Кто-нибудь знает или может указать причину, по которой нечто столь простое, как это, было «заменено» чем-то вроде этого:

Date d = null;
Calendar cal = GregorianCalendar.getInstance();
cal.set(1900 + year, month, day);
d = cal.getTime();

Теперь, очевидно, предупреждения об устаревании сами по себе не являются проблемой, но можете ли вы представить себе миллионы LOC, которые выкрикивали бы в агонии, если бы этот конструктор был когда-либо удален?

В моей короткой небольшой игре по бенчмаркингу последнее занимает примерно на 50% больше времени для выполнения.

Answer 1

Изначально Date должен был содержать всю логику, касающуюся дат, но разработчики API в конце концов поняли, что API, который у них был до сих пор, был ужасно неадекватным и не мог быть чисто расширен для правильного решения таких проблем, как часовые пояса, локали различные календари, летнее время и т. д.

Таким образом, они создали Calendar, чтобы справиться со всей этой сложностью, и отправили Date на простую временную метку, исключив все ее функции, связанные с форматированием, анализом и отдельными полями даты.

Кстати, внутренне эти методы, такие как конструктор Date(int, int, int), теперь вызывают Calendar, поэтому, если вы видите разницу в скорости, вы делаете что-то не так при вызове Calendar.

Итог: это не API Calendar Java, который слишком сложен, это человеческая концепция дат, и единственная проблема с Calendar заключается в том, что он предлагает не так много ярлыков для наиболее распространенных видов использования.

Answer 2

API Java Date уже давно подвергнуты критике, см., Например, этот поток .

Возможно, вы захотите проверить Joda-Time или Apache Commons Lang для альтернативных утилит даты / времени.

Answer 3

Ответ - мобильность.

Класс Date не очень гибкий. Вы можете определить даты, но не с любым преобразованием в другие форматы календаря. Поэтому Sun решила использовать дополнительную иерархию классов (Calendar), чтобы сделать ее более гибкой.

Тем не менее, это не очень удобно.

Answer 4

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

Однако Date все еще используется и очень хорошо используется в объектах значений или, скажем, в качестве типа данных. Поскольку вы делаете его неизменным явно, вы можете пойти с легкостью. Я склонен думать, что он должен быть неизменным, для других целей у нас есть календарь для манипулирования. Там, где ожидается множество манипуляций, нужно подумать о чем-то вроде Joda-Time.

[Изменено]

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

Answer 5

Технически, у Михаэля Боргвардта был лучший ответ. Но почему он обвиняет людей в том, как устроена наша солнечная система?

Хорошо, у нас появилась идея секунд, минут и часов.

Но мы не виноваты в том, что этот земной день приблизителен (в зависимости от того, говорим ли мы об истинном солнечном дне, среднем солнечном дне или звездном дне, каждый из которых меняется периодически и случайно). Мы не виноваты в том, что время орбиты Земли вокруг Солнца составляет приблизительно 365 дней, и мы не виноваты в том, что орбита Луны вокруг Земли составляет приблизительно 27,3 дня (в зависимости от о том, говорим ли мы о звездном, синодическом, тропическом, аномалистическом или драконическом (узловом) месяце).

Разве вы не рады, что Календарь не принял во внимание все эти детали? Тогда наши программные ошибки действительно могут зависеть от фазы луны.

Answer 6

Конечно, никто никогда не использует какой-либо другой формат календаря, но новый API увеличивает объем кода, который нужно написать для 99% общего случая, поэтому это отличная возможность для программистов Java, оплачиваемых LoC.