• Post Reply Bookmark Topic Watch Topic
  • New Topic

java.util.date v/s java.sql.date  RSS feed

 
Vaibhav Gargs
Ranch Hand
Posts: 116
2
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have certain doubts regarding util.date & sql.date:

1. Why do we have 2 different classes: java.util.date & java.sql.date?

2. Can't we have just one java.util.date and ignore the time part while dealing with JDBC APIs?

3. Which one to use when?
 
Stephan van Hulst
Saloon Keeper
Posts: 7991
143
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
java.util.Date was the old general purpose way of dealing with dates and times in Java programs. java.sql.Date is used to store dates in databases. I suppose the designers of java.sql didn't believe that the general purpose classes worked well inside their API. I don't blame them. java.util.Date is horrible and should be forgotten as soon as possible.

When to use java.util.Date? NEVER.

When to use java.sql classes? ONLY when writing or reading a date or time to or from the database.

What to use everywhere else? The new java.time API. Since Java 8, there are the LocalDate, LocalTime, LocalDateTime and much more useful classes to work with dates and times. you should perform all your calculations using these classes, and convert them to java.sql objects just before you write them to the database. java.sql.Date, java.sql.Time and java.sql.Timestamp have methods that allow you to convert between them and their java.time equivalents.
 
Vaibhav Gargs
Ranch Hand
Posts: 116
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Stephan!

Can you please specify the reason why we should never use java.util.date?

Also, is there a way we can store the java.util.date or JDK8 datetime to database directly? What is the harm in it i.e. why we should use java.sql.date only while dealing with DB?
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
java.util.Date is a badly designed class. Here is an article that explains a list of things that is wrong with it: All about java.util.Date

Since Java 8 there is a new date and time API, in the package java.time. It contains lots of classes for dealing with date and time that are much better designed and much more powerful than the old java.util.Date.

Unfortunately you often still have to deal with java.util.Date and java.sql.Date, because these have been in Java for a long time and a lot of code, including a lot of libraries have been written in the past 20 years using these classes.

Java's standard database APIs (JDBC and JPA) unfortunately do not (yet) have standard support for the new java.time classes, so it's not possible to directly use LocalDate, LocalTime, LocalDateTime etc. with JDBC and JPA - to be able to use them, you either have to convert to and from java.sql.Date and java.sql.Timestamp manually for each database interaction (which is cumbersome), or you have to install a type converter / adapter that automatically does that translation.
 
Vaibhav Gargs
Ranch Hand
Posts: 116
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Jesper!

So, why JDBC was not designed to deal with java.util.date? Why there were two classes initially: java.util.date/java.sql.date?
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Vaibhav Gargs wrote:So, why JDBC was not designed to deal with java.util.date? Why there were two classes initially: java.util.date/java.sql.date?

Probably because java.util.Date lacked some things that were necessary to make it work as it should to conform to the SQL type DATE; the API documentation of java.sql.Date says something about this:
API documentation wrote:To conform with the definition of SQL DATE, the millisecond values wrapped by a java.sql.Date instance must be 'normalized' by setting the hours, minutes, seconds, and milliseconds to zero in the particular time zone with which the instance is associated.

It's all quite badly designed, but we're stuck with it...
 
Vaibhav Gargs
Ranch Hand
Posts: 116
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Jesper. But, couldn't Java designers fix the java.util.date API itself to work it well with SQL standards?
 
Dave Tolls
Ranch Foreman
Posts: 3065
37
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But that would be shoehorning the util.Date based on the requirements for a different framework.

Creating a new Date (well, a wrapper) that handles the specific requirements for mapping between a database column and Java makes some sense.
In any case a sql.Date is a util.Date, it's just a wrapper to handle the specifics mentioned.
 
Stephan van Hulst
Saloon Keeper
Posts: 7991
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The Java designers couldn't even fix the java.util.Date class to work well in the first place (despite trying, look at all the deprecated members!), let alone to work well with other standards. In the end, they chose to abandon it completely in favor of the java.time API.

The java.sql APIs could be improved with default methods that accept java.time objects. Maybe they will do that in the future.
 
Liutauras Vilda
Sheriff
Posts: 4923
334
BSD
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
java.time [LocalDate; LocalTime; LocalDateTime] uses DateTimeFormatter for formatting purposes.

Does that mean, that SimpleDateFormat going to lose its use too? (apart from the need to support old code)
 
Dave Tolls
Ranch Foreman
Posts: 3065
37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:
The java.sql APIs could be improved with default methods that accept java.time objects. Maybe they will do that in the future.


Oh yes.  I live in hope, but I'm not holding my breath, considering JDBC is only a set of interfaces, and it's everyone else who produce the actual drivers that would end up doing the work.

Be nice to have the option, though...
 
Stephan van Hulst
Saloon Keeper
Posts: 7991
143
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes. Note however that you only need to use a DateTimeFormatter if you're going to parse dates or times. If you only want to format dates and times, you can just use String.format() and PrintWriter.printf(). The conversions that you could use for java.util.Date also work for any TemporalAccessor:
 
Stephan van Hulst
Saloon Keeper
Posts: 7991
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave Tolls wrote:Oh yes.  I live in hope, but I'm not holding my breath, considering JDBC is only a set of interfaces, and it's everyone else who produce the actual drivers that would end up doing the work.

Doesn't matter. You can give default implementations based on existing method signatures. For instance, in PreparedStatement:
 
Campbell Ritchie
Marshal
Posts: 56570
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:. . . they chose to abandon it completely in favor of the java.time API. . . .
You mean put it out of its misery?
 
Liutauras Vilda
Sheriff
Posts: 4923
334
BSD
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Vaibhav, Cowgratulations, your topic has been published in our July's Edition Journal.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!