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
