Re: Timestamp weirdness

On 26-Jul-05, at 10:28 AM, Kevin Grittner wrote:

> 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?
This looks like it may happen
>
> (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?
>
Generally we are more SQL compliant than any other database. This is the
first instance I've heard of that we aren't
> 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.
There are connection parameters to do exactly that.
http://jdbc.postgresql.org/documentation/80/connect.html#connection-
parameters
>
> -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.
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
>