开发者

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.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜