Allowed conversions of java.time Objects

[Mark Rotteveel]

On 12-2-2014 22:53, Lance Andersen - Oracle wrote:
>
> On Feb 12, 2014, at 4:28 PM, Mark Rotteveel wrote:
>
>> I am currently implementing some of the new java.time conversions for JDBC 4.2 and I am wondering if there might be some conversions missing from the changelog.
>>
>> According to the changelog (https://jcp.org/aboutJava/communityprocess/maintenance/jsr221/JDBC4.2MR-Oct232013.pdf) the Table B-5 mapping for java.time.LocalDate is:
>> CHAR, VARCHAR, LONGVARCHAR and DATE
>>
>> In this list I'd also expect TIMESTAMP (as a similar mapping does exist for java.sql.Date).
>>
>> Similarly the mapping for LocalTime also misses TIMESTAMP (as does exist for java.sql.Time).
>
> We had talked about this earlier and there really is no way to convert these given the specific properties of the objects (i.e. no time or date)

A LocalDate can be converted to a TIMESTAMP with the time portion set to 
00:00:00.0000; this matches with the JDBC rule that dates and times are 
considered to be in the JVM timezone, and is the behavior when calling 
setDate or setObject with a java.sql.Date on a TIMESTAMP field in most 
implementations.

So should the existing mapping for java.sql.Date to TIMESTAMP and 
java.sql.Time to TIMESTAMP in Table B-5 be considered 
deprecated/discouraged?

>> Is this intentional, or an omission? If the former: what is the rationale?
> Intentional
>>
>> Similarly: shouldn't a conversion from OffsetTime and OffsetDateTime to TIME respectively TIMESTAMP be allowed as well?
>
> TIMESTAMP and TIME do not represent any Timezone

When working with a database that doesn't support timezones, being able 
to store the LocalTime resp LocalDateTime equivalent for the JVM 
timezone might be an acceptable workaround. And when the same code can 
also run on databases to do support timezones you might not want to 
handle these exceptions.

Mark
-- 
Mark Rotteveel