This raises two questions for me, as someone trying to become acclimated
to the PostgreSQL development community.
(1) Is there any long-term goal of making the TIMESTAMP WITH TIME ZONE
more compatible with the standard by storing a time zone with the
timestamp?
(2) What is the general position of the PostgreSQL community regarding
the sticky questions of whether to improve compliance with standards
versus preserving existing (noncompliant) behavior to avoid breaking
existing PostgreSQL-specific application code?
Coming from years of working with Sybase databases, I have to say that I
appreciate the strategy they use in their JDBC driver. They provide a
connection property to specify the version of the to which driver you're
coding, and the behavior of existing code never changes (other than
clear bug fixes) for a given value of that property. If you want the
modified behavior, you change your code to work with it, and change the
property to match. It's a little clumsy, because there may be several
changes in one new version, and you need to adopt all or none, but it
does help. A more refined approach would provide properties to control
each individual behavior, and the version number would provide defaults.
-Kevin
>>> Oliver Jowett <oliver@opencloud.com> 07/25/05 8:12 PM >>>
emergency.shower@gmail.com wrote:
> If I TIMESTAMP WITH TIME ZONE is implemented on the server as a
> (timestamp, time zone)-pair
It's not, it's just a timestamp in UTC with no timezone stored.
> , the server should be able to cast
> TIMESTAMP WITH TIME ZONE correctly to TIMESTAMP WITHOUT TIME ZONE as
> described in the SQL standard:
>
> From TIMESTAMP WITH TIME ZONE to TIMESTAMP WITHOUT TIME ZONE
> TargetValue = SourceValue.UTC + SourceValue.TimeZone
I'd like to see this too, but Tom doesn't like it for
backwards-compatibility reasons.