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