Skip to main content

I hate java.sql.Date

5 replies [Last post]
Joined: 2006-01-07

java.sql.Date, Time, Timestamp were a bad idea from the beginning, but especially java.sql.Date. I can't imagine anyone thinking giving two classes the same name, when they are, more often than not, used in the same code was a good idea. :( I can see absolutely no need for them. You could still ahve get/setDate, time, timestamp method on PreparedStatement and ResultSet using java.util.Date.

Now, of course, because implementations of ResultSet and PreparedStatement have been written by many third parties it's not easy to put it right. However, one small consession: Why not give the java.sql.Date etc. constructors from java.util.Date? (And perhaps a valueOf() method).

Having to put:

<br />
java.sql.Date data = new java.sql.Date(dateFormat.parse(dateStr).getTime());</p>

is adding insult to injury.

This should be trivial to do, these classes are not third party.

In the long term let's have versions of setDate, setTimestamp and setTime which take java.util.Date.

(I appreciate that there's still a case for distinction in he single case of PreparedStatement.setObject())

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-13

I can appreciate your frustration. We will be looking at areas for improvement in the next release of the JDBC specification.


Joined: 2004-09-14

> I can appreciate your frustration. We will be
> looking at areas for improvement in the next release
> of the JDBC specification.

It might be better to define classes called:

* SqlDate
* SqlTime
* SqlTimeStamp

...which would not extend Date or Calendar, but which would be interoperable (as in, you could have constructors for SqlDate which accept legacy classes: java.util.Calendar, java.util.Date, and the java.sql subclass). You could also have methods such as "toDate()" and "toTimeStamp()" to export as a legacy class, also for interoperability.

If bundling Joda-Time is out of the question for Java 7, you could at the very least use that API as inspiration for any replacement. In particular, it'd be nice to have immutability, a concept of duration, and ability to have dates-without-time and times-without-date.

- Chris

Joined: 2006-01-07

No way that java.util.Date and Calendar are likely to be considered "legacy" classes (there's plenty of Date use outside of SQL) and one of the few saving graces of the current java.sql classes are that they extend java.util.Date, so that you can ignore their existence when reading dates, timestamps etc..

Joined: 2006-02-19

A lot of people had the same reaction about 8 or 9 years ago.

Joined: 2004-06-22

Another bad thing about sql Date is that it has different timezone semantics from util Date when you format them for display. You end up having to construct one from the timestamp of the other in order to normalise the behaviour.