Re: nasty problem with redhat 6.2 + pg 7.02

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: leonbloy(at)sinectis(dot)com(dot)ar
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, pgsql-general(at)postgresql(dot)org
Subject: Re: nasty problem with redhat 6.2 + pg 7.02
Date: 2000-09-19 21:26:32
Message-ID: 15014.969398792@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

leonbloy(at)sinectis(dot)com(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Buddy Lee Haystack 2000-09-19 21:40:12 pqReadData() -- backend closed the channel unexpectedly
Previous Message Edward Q. Bridges 2000-09-19 20:57:11 Re: nasty problem with redhat 6.2 + pg 7.02