3) seems most desirable to me, too.
What type would your "TZ" column have? Just a numeric offset? Or a VARCHAR,
also capable of storing textual TZ representations such as "+01:00
Europe/Paris"? I think the latter would be needed to make it fully
reflexive for ZonedDateTime.
Another variant of 3) could be to leverage DB-specific types such as
TIMESTAMP WITH TIME ZONE on Oracle. I could imagine that'd be what users of
databases supporting such a type might want.
--Gunnar
2015-03-24 3:00 GMT+01:00 Steve Ebersole <steve(a)hibernate.org>:
Not in the same Type. But of course "Type swapping" is so
easy nowadays...
On Mon, Mar 23, 2015 at 4:01 PM, Hardy Ferentschik <hardy(a)hibernate.org>
wrote:
> > A few options:
> >
> > 1) Forego OffsetDateTime, OffsetTime and ZonedDateTime support and just
> > stick with LocalDateTime, LocalDate and LocalTime.
> > 2) Use the timezone/offset to pass along to the driver (for proper
> > conversion); when reading back we'd have to read back based on the
> default
> > timezone. This is essentially the old strategy used in CalendarType
> which
> > I never really liked because its not reflexive.
> > 3) Break them into a tuple of the store each piece. E.g., for
> > OffsetDateTime the Tuple is a LocalDateTime (the Timestamp) and a TZ
> > offset. So we'd store each individually in the database and be able to
> > rebuild them in a fully reflexive manner.
> > 4) Handle them using UTC or GMT at the JDBC level. This is essentially
> the
> > same as (2)
>
> Personally, I think I'd prefer #3. I am not sure whether all users would
> be happy
> with two columns for a OffsetDateTime. Could we support multiple options,
> for example
> #3 and #4 and make it configurable?
>
> --Hardy
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev