> 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
pgpTMvZfr7Xcy.pgp
Description: PGP signature
_______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
