Why is the java.util.Date setTime () method not deprecated?

All other mutators are deprecated in JDK 1.1, so why did setTime() remain as it is? Of course, java.util.Calendar - the right way to manipulate dates - can create new instances of java.util.Date as needed using the java.util.Date(long) constructor?

+4
source share
3 answers

Date bits that were obsolete were those bits that were related to calendars (e.g. day, month, year, etc.). You will notice that access methods for calendar fields are also outdated, not just mutators.

However, the representation as a value in milliseconds is still how Date works and is not related to the calendar view, so it remained unreliable.

+6
source

Other mutators tried to use java.util.Date as a calendar, rather than instant time, wrapping a few milliseconds from January 1, 1970, at 12 UTC. Thus, it makes sense that one mutator is not obsolete.

The Date / Calendar APIs are still terrible, and you should still use Joda Time where possible - but I can see why this call was not deprecated. You cannot make the type immutable after this fact, and that was not the goal of obsolescence - it was an attempt to prevent people from using it as storage for June 19, 1976, etc.

+4
source

Since the setTime method is at least logically correct: the setX methods that take a day, a month, etc., do not make sense: java Date is a point in time and, therefore, a day, hour, month, etc. refer only to the Date view in a particular TimeZone .

+2
source

All Articles