Allowed conversions of java.time Objects

[Lance Andersen - Oracle]

On Feb 12, 2014, at 5:06 PM, Mark Rotteveel wrote:

> 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?

There is too much history and headaches with the existing java.sql.* datetime classes, where we need to leave as is and not migrate behavior when it really does not warrant it.

LocalDate.asStartOfDay() could be used to create a LocalDateTime if someone desires
> 
>>> 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.

Someone could certainly  do an OffsetTime.toLocalTime() if they really wanted.

The current goal is not to do more than is needed.  We can always adjust with continued feedback but for now that is where we are for JDBC 4.2.

Once we get more feedback we can possibly revisit.    


Best
Lance
> 
> Mark
> -- 
> Mark Rotteveel

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com