Re: nasty problem with redhat 6.2 + pg 7.02

Lamar Owen <lamar.owen@wgcr.org> writes:
> leonbloy@sinectis.com.ar wrote:
>> [postgres@ren postgres]$ echo "select * from serv2;" | psql test1
>> fecha1   |   fecha2
>> ------------+------------
>> 13-01-2000 | 30-09-2000
>> (1 row)

>> ?????? What's happening here ???

> I can't duplicate:

You won't duplicate it on that date, unless you are in the same timezone
he is --- I believe it's a daylight-savings-transition issue.  Attached
are some comments I sent to Hernan privately.

            regards, tom lane


To: Hernan Gonzalez <hgonzal@sinectis.com.ar>
Subject: Re: problem with postgres
Date: Fri, 15 Sep 2000 19:02:06 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>

Hernan <hgonzal@sinectis.com.ar> writes:
>  The 'lost day' ( 01-10-2000 => 30-09-2000 ) occurs with
>  that date only, first october 2000... at least, I haven't found any
>  other example

Would that happen to be a daylight-savings transition boundary in your
timezone?

There have been some discussions recently about whether conversions
between timestamp and date behave reasonably at a DST boundary.  It's
possible that you're getting bit by a bug of that sort, though I
wouldn't have thought it'd happen without a datatype conversion.

In my zone (EST5EDT) Postgres 7.0.2 has this problem on the spring
transition date:

play=> select '2000-04-02'::date;
  ?column?
------------
 2000-04-02
(1 row)

play=> select '2000-04-02'::date::timestamp;
        ?column?
------------------------
 2000-04-01 23:00:00-05                <<=== oops, off by an hour
(1 row)

play=> select '2000-04-02'::date::timestamp::date;
  ?column?
------------
 2000-04-01
(1 row)

This is fixed in current sources for 7.1.  I don't see how this would
apply to just inserting data into a date column, but maybe there's
some related problem that's biting you.

            regards, tom lane