Package net.time4j.sql

Class JDBCAdapter<S,​T>

java.lang.Object
net.time4j.TemporalType<S,​T>
net.time4j.sql.JDBCAdapter<S,​T>
Type Parameters:
S - source type in JDBC
T - target type in Time4J
All Implemented Interfaces:
Converter<S,​T>
public abstract class JDBCAdapter<S,​T> extends TemporalType<S,​T>

Serves as bridge to temporal types in JDBC.

All singleton instances are defined as static constants and are immutable.

Since:
3.0
Author:
Meno Hochschild

  • Field Details

    • SQL_DATE

      public static final JDBCAdapter<Date,​PlainDate> SQL_DATE

      Bridge between a JDBC-Date and the class PlainDate.

      If the system property "net.time4j.sql.utc.conversion" is set to the value "true" then the conversion will not take into account the system timezone anticipating that a SQL-DATE was created without any timezone calculation on the server side, too. That is more or less the case if UTC is the default timezone on the application server.

      Example (UTC as default timezone):

        java.sql.Date sqlValue = new java.sql.Date(86400 * 1000);
  PlainDate date = JDBCAdapter.SQL_DATE.translate(sqlValue);
  System.out.println(date);
  // output: 1970-01-02

      Note: The conversion is only possible if a date has a year in the range 1900-9999 because else a JDBC-compatible database cannot store the date per SQL-specification. It is strongly recommended to interprete a SQL-DATE only as abstract JDBC object because its text output via java.sql.Date.toString()-method is not reliable (dependency on the gregorian-julian cutover day + possible timezone side effects). The concrete formatting can be done by Time4J for example via PlainDate.toString() or a suitable ChronoFormatter.

      Since:
      3.0

    • SQL_TIME

      public static final JDBCAdapter<Time,​PlainTime> SQL_TIME

      Bridge between a JDBC-Time and the class PlainTime.

      If the system property "net.time4j.sql.utc.conversion" is set to the value "true" then the conversion will NOT take into account the system timezone anticipating that a SQL-DATE was created without any timezone calculation on the server side, too. That is more or less the case if UTC is the default timezone on the application server.

      Example (UTC as default timezone):

        java.sql.Time sqlValue = new java.sql.Time(43200 * 1000);
  PlainTime time = JDBCAdapter.SQL_TIME.translate(sqlValue);
  System.out.println(time);
  // output: T12:00:00

      Note: The conversion only occurs in millisecond precision at best not in in nanosecond precision so there is possible loss of data. Furthermore, the text output via the method java.sql.Time.toString() can be misinterpreted by timezone side effects. Concrete text output should be done by Time4J.

      Since:
      3.0

    • SQL_TIMESTAMP

      public static final JDBCAdapter<Timestamp,​PlainTimestamp> SQL_TIMESTAMP

      Bridge between a JDBC-Timestamp and the class PlainTimestamp.

      If the system property "net.time4j.sql.utc.conversion" is set to the value "true" then the conversion will NOT take into account the system timezone anticipating that a SQL-DATE was created without any timezone calculation on the server side, too. That is more or less the case if UTC is the default timezone on the application server.

      Example (UTC as default timezone):

        java.sql.Timestamp sqlValue = new java.sql.Timestamp(86401 * 1000);
  sqlValue.setNanos(1);
  PlainTimestamp ts = JDBCAdapter.SQL_TIMESTAMP.translate(sqlValue);
  System.out.println(ts);
  // output: 1970-01-02T00:00:01,000000001
      Since:
      3.0

    • SQL_TIMESTAMP_WITH_ZONE

      public static final JDBCAdapter<Timestamp,​Moment> SQL_TIMESTAMP_WITH_ZONE

      Bridge between a JDBC-Timestamp and the class Moment.

      Notes: Leap seconds are not storable. And the maximum available precision is dependent on the database. Despite of the misleading SQL name, this conversion does not use a timezone but a timezone offset, finally ZonalOffset.UTC.

      Since:
      3.18/4.14