Почему метод setTime () из java.util.Date не считается устаревшим?

Question

Все остальные мутаторы были объявлены устаревшими в JDK 1.1, так почему же setTime() остался как есть? Конечно, java.util.Calendar - правильный способ манипулирования датами - может создавать новые экземпляры java.util.Date по мере необходимости, используя конструктор java.util.Date(long)?

Answer 1

Биты Date, которые были объявлены устаревшими, были теми битами, которые относились к календарям (т.е. день, месяц, год и т. Д.). Вы заметите, что методы доступа для полей календаря также устарели, а не только мутаторы.

Представление в виде значения в миллисекундах, тем не менее, по-прежнему работает Date и не связано с представлением в календаре, поэтому оно оставалось неопределенным.

Answer 2

Другие мутаторы пытались использовать java.util.Date как календарь, а не как мгновение во времени, оборачивая количество миллисекунд с 1 января 1970 года в 12:00 UTC. Таким образом, имеет смысл, чтобы этот мутатор не был признан устаревшим.

API Date / Calendar, конечно, все еще ужасны, и вы все равно должны использовать Joda Time везде, где это возможно, но я понимаю, почему этот вызов не был объявлен устаревшим Вы не можете сделать тип неизменяемым после факта, и это не было целью устаревания - цель состояла в том, чтобы попытаться помешать людям использовать его в качестве хранилища для «19 июня 1976 года» и т. Д.

Answer 3

Поскольку метод setTime по крайней мере логически корректен: методы setX, которые занимают день , месяц и т. Д., Не имеют смысла: java Date является мгновенное время и, следовательно, день , час , месяц и т. Д. Относятся только к представлению этого Date в конкретном TimeZone .