The real difficulty with (3) is querying. How do you restrict a query on a
(TIMESTAMP,TZ) tuple for example when the individual values could be in
multiple timezones? Andrea and I were just discussing the same in regards
to Java 9(?) Money/Currency support.
Personally I think this idea of trying
Forcing 3 is correct but rarely desirable, I'm afraid the user should choose.
But most people will not like the additional
space/performance/complexity hit, and will use a single timezone.
If you think we should force people into a correct choice, you'd
require 3# unless they are willing to set a
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)
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
wrote:
> > A few options:
> >
> > 1) Forego OffsetDateTime, OffsetTime and ZonedDateTime support and just
> > stick with LocalDateTime, LocalDate and LocalTime.
> > 2) U
> 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
> time
