All the other mutators got deprecated back in JDK 1.1, so why was setTime() left as is? Surely java.util.Calendar - the correct way to manipulate dates - can create new instances of java.util.Date as needed using the java.util.Date(long) constructor?
+6
A:
The bits of Date that were deprecated were those bits that related to calendars (i.e. day, month, year, etc). You'll note that the accessor methods for calendar fields are also deprecated, not just the mutators.
The representation as a milliseconds value, however, is still the way Date works, and is unrelated to the calendar representation, so it stayed as undeprecated.
skaffman
2009-10-12 21:39:36
+2
A:
Because the setTime method is at least logically correct: the setX methods which take day, month etc make no sense: a java Date is an instant in time and hence day, hour, month etc relate only to the view of that Date in a particular TimeZone.
oxbow_lakes
2009-10-12 21:40:31
+3
A:
The other mutators were trying to use java.util.Date as a calendar, rather than as an instant in time, wrapping a number of milliseconds since Jan 1st 1970 12am UTC. As such, it makes sense for that one mutator not to be deprecated.
The Date/Calendar APIs are still terrible of course, and you should still use Joda Time wherever possible - but I can see why that call wasn't deprecated. You can't make a type immutable after the fact, and that wasn't the point of the deprecation - the point was to try to stop people from using it as storage for "June 19th 1976" etc.
Jon Skeet
2009-10-12 21:40:59