Re: nasty problem with redhat 6.2 + pg 7.02 - Mailing list pgsql-general

From Tom Lane
Subject Re: nasty problem with redhat 6.2 + pg 7.02
Date
Msg-id 15014.969398792@sss.pgh.pa.us
Whole thread Raw
In response to Re: nasty problem with redhat 6.2 + pg 7.02  (leonbloy@sinectis.com.ar)
List pgsql-general
leonbloy@sinectis.com.ar writes:
> test6=# select '01-10-2000'::date::timestamp;
>            ?column?
> ------------------------------
>  Sat 30 Sep 23:00:00 2000 ART
> (1 row)

> test6=# select '13-10-2000'::date::timestamp;
>            ?column?
> -------------------------------
>  Fri 13 Oct 00:00:00 2000 ARST
> (1 row)

> test6=# select '01-10-2000'::date::timestamp;
>            ?column?
> ------------------------------
>  Sat 30 Sep 00:00:00 2000 ART
> (1 row)

> The first result (30 sept 23:00:00) is obviously due to
> a timezone-daylight saving issue.
> But why postgresql throws a different result afterwards,
> is more than I can explain.

I'll bet there is some bit of internal state somewhere that affects
the results.  It could be inside libc, or it could be in Postgres.
I seem to recall that we have some timezone info that gets computed
on the first call of a timezone-related operation and then saved
thereafter; maybe that's related somehow.  libc probably also saves
timezone information across calls.  If you alter the order of the
inquiries, how do the results change?

Thomas Lockhart is our lead guy on date/time operations, and it's
clearly time to get him involved.  Thomas, have you noticed this
thread?  Any luck reproducing the problem?

            regards, tom lane

pgsql-general by date:

Previous
From: "Jonathan Boarman"
Date:
Subject: Q: CAN TRANSACTION LOGGING BE DISABLED?
Next
From: Buddy Lee Haystack
Date:
Subject: pqReadData() -- backend closed the channel unexpectedly