I am trying to understand why we would need these TemporalType additions.
TemporalType really serves 2 purposes, imo:
1. indicates a precision for the temporal values in terms of DB storage
2. indicates the concrete `java.util.Date` subclass to use in the model
If the application model defines the attribute as `java.util.Date` we need
to know whether it represents a DATE, TIME or TIMESTAMP. Really this is a
short-coming of the old (pre-8) temporal types in that the concrete
temporal types are only available in `java.sql` flavors and most developers
do not want to expose JDBC types in their model. Otherwise, if the
application model defined attributes using the concrete `java.util.Date`
sub-types then the TemporalType would not really be needed; we'd know based
on the attribute type.
In terms of support for Java 8 temporal values, the "precision" aspect does
not change - a database can still only store temporal values in a discrete
number of ways that already line up with the TemporalType values.
Now... if the thought process is to allow the application model to define
attributes of type `java.time.temporal.Temporal` then yes I can see the
need to allow the application to indicate which specific concrete type to
use. However, from the `java.time.temporal.Temporal` javadocs:
<quote>
This interface is a framework-level interface that should not be widely
used in application code. Instead, applications should create and pass
around instances of concrete types, such as LocalDate. There are many
reasons for this, part of which is that implementations of this interface
may be in calendar systems other than ISO. See ChronoLocalDate
<
https://docs.oracle.com/javase/8/docs/api/java/time/chrono/ChronoLocalDate.html>
for a fuller discussion of the issues.
</quote>
So unless we plan on breaking that intended use and supporting models that
expose attributes of type `java.time.temporal.Temporal` rather than the
concrete types I just am not seeing why we need these added TemporalType
values.
Now IMO there is a discussion to be had in regards to temporal value
storage and timezones, but that is another discussion.
On Tue, May 2, 2017 at 6:43 AM Werner Keil <werner.keil_at_gmail.com> wrote:
> I admit, it probably exceeds a simple MR, but since at least Bean
> Validation 2 adds java.time support for Java EE 8 I wonder, if
> https://java.net/jira/browse/JPA_SPEC-63 was addressable or not for EE 8?
>
> I am also aware of the gross incompatibility of e.g. java.sql.Time etc.
> and the types in java.time all of which are final, so it does not look like
> the underlying JDBC in 4.2 or beyond is able to support all of it, but
> could e.g. TemporalType get further variations including "LOCAL_DATE_TIME",
> "INSTANT" or whatever seems appropriate?
>
> Werner
>