0

In java why so much. date and time handling features

eg

java.util , java.sql , calendar , java 8 Date and Time

  1. can we use java.util to save in the database. if so then why java.sql introduced
  2. while inserting into database should we convert the java.util to java.sql and then save. if so then what will be benefits of it
M. Deinum
  • 115,695
  • 22
  • 220
  • 224
sagar k
  • 35
  • 5
  • 1
    Because things improve over time. You should use `java.time.*` for new code. There are varying ways to work with those classes and databases. – Kayaman Feb 03 '20 at 14:21
  • See also https://stackoverflow.com/q/1969442/2448440 and https://stackoverflow.com/q/8511430/2448440 for `java.util` vs `java.time` and that Joda-Time that everyone was talking about before Java 8. The basic reason for `java.util`s time is "Backwards compatibility" – Qw3ry Feb 03 '20 at 15:02

2 Answers2

4

tl;dr

  • Use only java.time classes.
  • Never use date-time classes in the java.util and java.sql packages.

You asked:

can we use java.util to save in the database. if so then why java.sql introduced

Use neither. Both are now outmoded by the java.time classes.

And you asked:

while inserting into database should we convert the java.util to java.sql and then save. if so then what will be benefits of it

Use neither. Use only the java.time classes. 

myPreparedStatement.setObject( … , myOffsetDatetime ) ;

…and:

OffsetDateTime myOffsetDateTime = myResultSet.getObject( … , OffsetDateTime.class ) ;

JSR 310

You asked:

In java why so much. date and time handling features

The date-time classes in the java.util and java.sql packages are terribly flawed in their design. They were built decades ago by people who did not understand the complexities and subtleties of date-time handling.

As a whole the information technology industry largely ignored mastering the details of date-time handling in programming. Quite astounding that so many decades passed with no real complete well-designed solution.

In 2014, the JCP community, including Sun/Oracle, voted unanimously to adopt JSR 310. The java.time classes became part of Java 8 and later. This framework is now leading the industry.

Adopting JSR 310 meant that the date-time classes in the java.util and java.sql packages became legacy, supplanted entirely by the java.time classes. At one point the legacy classes were marked for deprecation, then undone for reasons undisclosed.

Converting

No need for you to ever use those terrible legacy classes again. Avoid java.util.Date, Calendar, GregorianCalendar, SimpleDateFormat, java.sql.Date, and so on.

If interoperating with old code not yet updated for java.time, you can convert. Call the new to… and from… methods added to the old classes.

Back-ports

For Java 6 & 7, use the back-port library, ThreeTen-Backport. Further adapted for early Android (before 26) in the ThreeTeABP library.

JDBC

JDBC 4.2 and later requires support for exchanging java.time objects with the database. Your JDBC driver has likely been updated by now.

Learn about methods such as PreparedStatement::setObject and ResultSet::getObject.

For a moment, that is, for columns of a data type akin to the SQL-standard type TIMESTAMP WITH TIME ZONE, support for java.time.OffsetDateTime is required. Oddly, support for the more commonly used Instant and ZonedDateTime is not addressed in the JDBC specification. Your driver may or may not support those types. If not, you can easily convert by calling the at…, to…, and with… methods. To make your JDBC code more portable across drivers, exchange only OffsetDateTime objects, and convert to/from Instant/ZonedDateTime as needed.

OffsetDateTime odt = myResultSet.getObject( … , OffsetDateTime ) ;
ZoneId z = ZoneId.of( "Africa/Casablanca" ) ;
ZonedDate zdt = odt.atZoneSameInstant( z ) ;

For columns with only a date and a time-of-day but lacking the context of a time zone or an offset-from-UTC (therefore not a moment), that is, for a data-type akin to the SQL-standard TIMESTAMP WITHOUT TIME ZONE, use java.time.LocalDateTime.

Table of date-time types in Java (both legacy and modern) and in standard SQL

Evolution

The Joda-Time project is the predecessor to java.time. Lessons learned there were used in designing java.time. Joda-Time is now in maintenance-mode.

Joda-Time, JSR 310, java.time, ThreeTen-Backport, and ThreeTen-Extra are all led by the same man, Stephen Colebourne.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
  • _"Oddly, support for the more commonly used Instant and ZonedDateTime is optional."_ The JDBC specification doesn't even mention these types, so support for those types is not optional, supporting those would be non-standard extensions. – Mark Rotteveel Feb 03 '20 at 17:31
  • @MarkRotteveel if something is not required, and not forbidden, it is optional. And “optional” means other JDBC drivers may not support those types, so your code will not be portable across drivers. The point of your distinction escapes me. – Basil Bourque Feb 03 '20 at 17:34
  • In JDBC, optional features are features that are specified by the specification or API doc, but a driver is allowed to not implement an optional feature (and instead throw `SQLFeatureNotSupportedException`, or - for example in the `DatabaseMetaData` - return an empty result set). As JDBC does not define support for `Instant` or `ZonedDateTime`, those features are not optional, but non-standard. – Mark Rotteveel Feb 03 '20 at 17:37
  • @MarkRotteveel Very well, I changed the wording. Thank you for the clarification. – Basil Bourque Feb 03 '20 at 18:21
1

  1. java.util.Date can't be used to save in database, because there are 3 different data types on database side: DATE, TIME and TIMESPAMP. To reflect these 3 types the java.sql.Date, java.sql.Time and java.sql.Timespamp were introduced respectively

  2. Java 8 time API is recommended, there's no necessity anymore to use legacy and to deal with a converting between java.util and java.sql

edwgiz
  • 747
  • 5
  • 15