Why was "new Date(int year, int month, int day)" deprecated?

Question

My application I've recently inherited is FULL of deprecation warnings about the constructor:

Date d = new Date(int year, int month, int day)

Does anyone know or can point to a reason why something as simple as this was "replaced" with something like this:

Date d = null;
Calendar cal = GregorianCalendar.getInstance();
cal.set(1900 + year, month, day);
d = cal.getTime();

Now, obviously deprecation warnings are not a problem in themselves, but can you imagine the millions of LOC that would be crying out in agony if this constructor was ever removed?

In my brief little play at benchmarking, the latter takes about 50% more time to execute.

Isn't the first line a total waste of time? You get a Date from the cal to Calendar.getTime(), so why create one with the new Date() call that is then thrown away? Especially if you were benchmarking this ... — unwind, Jan 20 '09 at 08:35
Perhaps it's because the Americans were expecting Date (int year, int day, int month) ;-) — Skizz, Jan 20 '09 at 09:55
@unwind: sure, in this instance it may not make sense, but you don't always want a date of the current time, think birthdays, expiry date etc. — Scott Bennett-McLeish, Jan 20 '09 at 22:31
@Scott: Even then you can set it through cal.set(..), as you are doing. I believe, when you intend to use calendar, you should not instantiate your date like what you have done. — Adeel Ansari, Jan 21 '09 at 02:10
@Adeel I see your point but when the existing system is expecting a java.util.Date, you give a java.util.Date. Perhaps over time with a larger understanding of the system more could be done for refactoring out the older APIs. — Scott Bennett-McLeish, Jan 21 '09 at 04:37
for the record, check Java 8 new Date api! http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html — aldo.roman.nurena, Sep 11 '14 at 18:11

score 48 · Accepted Answer · answered Jan 20 '09 at 09:57

Originally, Date was intended to contain all logic concerning dates, but the API designers eventually realized that the API they had so far was woefully inadequate and could not be cleanly extended to deal correctly with issues such as timezones, locales, different calendars, daylight savings times, etc.

So they created Calendar to deal with all that complexity, and relegated Date to a simple timestamp, deprecating all its functionality that dealt with formatting, parsing and individual date fields.

BTW, internally these methods such as Date(int, int, int) constructor now call Calendar, so if you see a difference in speed, then you're doing something wrong when calling Calendar.

The bottomline: It's not Java's Calendar API that is overly complex, it's the human concept of dates, and the only problem with Calendar is that it offers not much in the way of shortcuts to the most common usages.

`java.util.Date` re-uses a static instance of the Gregorian Calendar. Which is interesting to say least. But will perform better then creating a new Calender for each loop. — Martin, Sep 09 '14 at 08:55

score 8 · Answer 2 · edited May 23 '17 at 10:29

8

The Java Date APIs have long been critized, see for instance this thread.

You might want to check out Joda-Time or Apache Commons Lang for alternative Date/Time utilities.

edited May 23 '17 at 10:29

Community

1
1

answered Jan 20 '09 at 08:11

Einar

3,279
2
26
28

I actually recall watching a presentation on Joda on Parleys a while back and being impressed. http://www.parleys.com/display/PARLEYS/Home#slide=1;title=JSR%20310%20-%20Date%20and%20Time%20API;talk=7602357. As for a retro-implementation into 100s of 1000s or LOC I'm not so sure. – Scott Bennett-McLeish Jan 21 '09 at 04:32
Good point. Joda-Time was later used as foundation for the development of [java.time, the modern Java date and time API](https://docs.oracle.com/javase/tutorial/datetime/). Built-in from Java 8, also [backported to Java 6 and 7](https://www.threeten.org/threetenbp/). It’s what I recommend we all use now. – Ole V.V. Sep 04 '19 at 10:42

score 7 · Answer 3 · edited Oct 21 '14 at 22:36

7

The answer is portability.

The class Date is not very flexible. You can define dates, but not with any transformation into other calendar formats. So Sun decided to use an additional class hierarchy (Calendar) to make it more flexible.

Nonetheless, it's not very handy.

edited Oct 21 '14 at 22:36

Ergwun

12,579
7
56
83

answered Jan 20 '09 at 08:08

guerda

23,388
27
97
146

Adeel Ansari · Answer 4 · 2009-01-20T09:39:25.563

Mostly because the original java.util.Date was bloated and not completely timezone aware and not internationalization friendly.

However, Date is still in use and very well, in Value Objects, or say as a data type. As far as you make it immutable explicitly, you can go with ease. I tend to think it must be immutable, for other purpose we have Calendar to manipulate. Where its lot of manipulation expected, one should consider something like, Joda-Time.

[Edited]

Just don't instantiate the Date, in the latter code. Its of no use. You may achieve a better result for your benchmark.

score 3 · Answer 5 · answered Jan 20 '09 at 11:59

3

Of course, no-one ever uses any other calendar format, but the new API increases the amount of code to write for the 99% common case, so it's a great boon for Java programmers paid by LoC.

answered Jan 20 '09 at 11:59

bobince

528,062
107
651
834

HA, surely in this day and age LoC isn't used as a metric of productivity? – Scott Bennett-McLeish Jan 20 '09 at 22:27
One would hope not, but perhaps the chaps at Sun who keep producing APIs like this haven't heard things have changed... – bobince Jan 20 '09 at 23:04

score 3 · Answer 6 · answered Mar 22 '11 at 14:13

Michael Borgwardt had the best answer, technically. But why is he blaming humans for the way our solar system is laid out?

OK, we came up with the idea of seconds, and minutes, and hours.

But it's not our fault that that Earth's day is approximate (depending on whether we're talking about true solar day, mean solar day, or stellar day, each of which varies periodically and randomly). It isn't our fault that the time of Earth's orbit around the Sun is approximately 365 days, and it's not our fault that the moon's orbit around the Earth is approximately 27.3 days (depending on whether we're talking about a sidereal, synodic, tropical, anomalistic, or draconic (nodical) month).

Aren't you glad that Calendar didn't take all those details into account? Then our software bugs might indeed be dependent on the phase of the moon.

Captain Obvious strikes again! No need to copy, just point. http://en.wikipedia.org/wiki/Gregorian_calendar — IceGlow, Nov 20 '12 at 12:33

Why was "new Date(int year, int month, int day)" deprecated?

6 Answers6

Linked