Thanks Linda, understandable. Mapping zoned/offset types is a tricky
subject overall, hence my objection to forcing providers to respect the
with or without variant of these database types.
A perfectly acceptable and widely used approach to storing dates and times
into the database is to convert all values to UTC, and hence storing the TZ
is rendundant. I don't think the approach a particular vendor chooses for
timezone handling ought to be limited here. In my opinion there should be
wording in these additions in the second paragraph under "11.1.6 Basic
Annotation" stating that providers are allowed to map values to use the
non-WITH_TIMEZONE variants.
On Thu, May 4, 2017 at 1:13 PM Linda DeMichiel <linda.demichiel_at_oracle.com>
wrote:
>
>
> On 5/4/17, 10:59 AM, Steve Ebersole wrote:
> > So long as we are not requiring providers to
> > chose TIMESTAMP_WITH_TIMEZONE/TIME_WITH_TIMEZONE as the mapping
> > for java.time.OffsetDatetime/java.time.OffsetTime then that text looks
> > good to me. Also, why no support for java.time.Zoned* variants?
> >
>
> Since this is only an MR, we wanted to provide something
> straightforward and simple enough to accommodate in the
> time frame that we have -- hence the restrictions to time
> types directly supported by JDBC.
>
> >
> > On Thu, May 4, 2017 at 12:26 PM Lukas Jungmann
> > <lukas.jungmann_at_oracle.com <mailto:lukas.jungmann_at_oracle.com>> wrote:
> >
> > Hi,
> >
> > for this, I think adding java.time.LocalDate,
> > java.time.LocalTime, java.time.LocalDateTime, java.time.OffsetTime
> > and java.time.OffsetDateTime can be acceptable and doable from JPA
> > MR perspective so it is on par with others such as JDBC. That means
> > following additions (in italics) to the spec, which I'd like to
> propose:
> >
> >
> > *2.2 Persistent Fields and Properties*
> > ...
> > The persistent fields or properties of an entity may be of the
> > following types: Java primitive types;
> > java.lang.String; other Java serializable types (including wrappers
> > of the primitive types,
> > java.math.BigInteger, java.math.BigDecimal, java.util.Date,
> > java.util.Calendar[5], java.sql.Date, java.sql.Time,
> java.sql.Timestamp,
> > byte[], Byte[], char[], Character[], /java.time.LocalDate,
> > java.time.LocalTime, java.time.LocalDateTime,
> > java.time.OffsetTime, java.time.OffsetDateTime,/ and user-defined
> > types that implement the Serializable
> > interface); enums; entity types; collections of entity types;
> > embeddable classes (see Section
> > 2.5); collections of basic and embeddable types (see Section 2.6).
> > …
> >
> >
> > *2.8 Mapping Defaults for Non-Relationship Fields or Properties*
> >
> > …
> > If the type of the field or property is one of the following, it is
> > mapped in the same way as it
> > would if it were annotated as Basic: Java primitive types, wrappers
> > of the primitive types,
> > java.lang.String, java.math.BigInteger, java.math.BigDecimal,
> > java.util.Date, java.util.Calendar, java.sql.Date, java.sql.Time,
> > java.sql.Timestamp, /java.time.LocalDate, java.time.LocalTime,
> > java.time.LocalDateTime, java.time.OffsetTime,
> > java.time.OffsetDateTime,/
> > byte[], Byte[], char[], Character[], enums, any other
> > type that implements Serializable. See Sections 11.1.6, 11.1.18,
> > 11.1.28, and 11.1.51.
> > …
> >
> >
> > *11.1.6 Basic Annotation*
> >
> > The Basic annotation is the simplest type of mapping to a database
> > column. The Basic annotation
> > can be applied to a persistent property or instance variable of any
> > of the following types: Java primitive
> > types, wrappers of the primitive types, java.lang.String,
> > java.math.BigInteger,
> > java.math.BigDecimal, java.util.Date, java.util.Calendar,
> java.sql.Date,
> > java.sql.Time, java.sql.Timestamp, /java.time.LocalDate,
> > java.time.LocalTime,//
> > //java.time.LocalDateTime, java.time.OffsetTime,
> > java.time.OffsetDateTime,/ byte[], Byte[], char[], Character[],
> > enums, and any other type that implements Serializable. As described
> > in Section 2.8, the use of
> > the Basic annotation is optional for persistent fields and
> > properties of these types. If the Basic annotation
> > is not specified for such a field or property, the default values of
> > the Basic annotation will apply.
> >
> > /Mapping of java.time.LocalDate, java.time.LocalTime,
> > java.time.LocalDateTime, java.time.OffsetTime
> > and java.time.OffsetDateTime types////to columns other than those
> > supported by the mappings defined by//
> > //Appendix B of the JDBC 4.2 specification is not required to
> > be////supported by the persistence provider
> > beyond the support required////for other serializable types./
> >
> > *
> > *
> >
> > *13. * *Related Documents*
> >
> > ...
> > [ 5 ] /JDBC 4.2 Specification./ http://jcp.org/en/jsr/detail?id=221.
> > ...
> >
> > WDYT?
> >
> > Thank you,
> > --lukas
> >
> >
> > On 5/2/17 1:42 PM, Werner Keil 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
> >
>