• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 441
2
Java
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Saloon Keeper
Posts: 15491
363
  • Likes 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 441
2
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 441
2
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 441
2
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Rancher
Posts: 4801
50
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 15491
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Marshal
Posts: 8856
637
Mac OS X VI Editor BSD Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Rancher
Posts: 4801
50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 15491
363
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 15491
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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:
 
Marshal
Posts: 79153
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Marshal
Posts: 8856
637
Mac OS X VI Editor BSD Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Vaibhav, Cowgratulations, your topic has been published in our July's Edition Journal.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic