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

Scott Bennett-McLeish picture Scott Bennett-McLeish · Jan 20, 2009 · Viewed 41k times · Source

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.

Answer

Michael Borgwardt picture Michael Borgwardt · Jan 20, 2009

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.