Why is java.util.Date's setTime() method not deprecated?
All the other mutators got deprecated back in JDK 1.1, so why was set开发者_如何学JAVATime()
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?
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.
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.
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
.
精彩评论