[threeten-dev] [threeten-develop] Integration with other JDK classes

[Stephen Colebourne]

On 5 December 2012 18:10, Douglas Surber <douglas.surber at oracle.com> wrote:
> Can you confirm that all of the following work in your proposal?
>   LocalTime t1 = LocalTime.from(aJavaSqlTime);
>   LocalTime t2 = LocalTime.from(aJavaSqlTimestamp);
>
>   LocalDate t3 = LocalDate.from(aJavaSqlDate);
>   LocalDate t4 = LocalDate.from(aJavaSqlTimestamp);
>
>   LocalDateTime t5 = LocalDateTime.from(aJavaSqlTimestamp);

I'm not sure I have a precise proposal ;-) None of them will happen
without work on the part of JDBC and agreement with Roger/Sherman.

To make the above work requires java.util.Date (or each of the three
subclasses) to implement DateTimeAccessor. Implementing that interface
is a reasonable size commitment, but does provide power as the
benefit. For example, implementing the interface would allow the
conversions above, and use of the sql classes in the 310 formatters.

The question is whether the value is really there to implement the
interface, or whether it causes more harm than good.

The alternative is to add
- sql.Time.toLocalTime()
- sql.Date.toLocalDate()
- sql.Timestamp.toLocalDateTime()

which allow fewer conversions (and less power) but also help
"encourage" users to use the 310 classes.

> With the addition methods
>
>    java.sql.Time t6 = java.sql.Time.from(aLocalTime);
>    java.sql.Date t7 = java.sql.Date.from(aLocalDate);
>    java.sql.Timestamp t8 = java.sql.Timestamp.from(aLocalDateTime);
>    java.sql.Timestamp t9 = java.sql.Timestamp.from(anOffsetDateTime);
>    java.sql.Timestamp t10 = java.sql.Timestamp.from(aZonedDateTime);

I do believe that adding from(DateTimeAccessor) to each of the three
sql classes would be beneficial if (and only if) you want developers
to carry on using those classes. Since JDBC will be updated to allow
use of LocalDate etc anyway, it could be argued that there will be no
need to convert to the sql classes in JDK8.

(BTW, the above assumes that Timestamp maps to LocalDateTime - I
assume that is the mapping the JDBC team has in their heads?

> I guess these would work as well.
>    java.sql.Time t11 = java.sql.Time.from(aLocalDateTime);
>    java.sql.Time t12 = java.sql.Time.from(anOffsetDateTime);
>    java.sql.Time t13 = java.sql.Time.from(aZonedDateTime);
>    java.sql.Date t14 = java.sql.Date.from(aLocalDateTime);
>    java.sql.Date t15 = java.sql.Date.from(anOffsetDateTime);
>    java.sql.Date t16 = java.sql.Date.from(aZonedDateTime);

If from(DateTimeAccessor) is added, all these would work.

> What happens with these?
>    OffsetDateTime t17 = OffsetDateTime.from(aJavaSqlTimestamp);
>    ZonedDateTime t18 = ZonedDateTime.from(aJavaSqlTimestamp);
>
> I would expect them to fail as java.sql.Timestamp does not have an
> offset or zone id.

These would fail, and would only compile if the sql classes implement
DateTimeAccessor.

Stephen