> > The first result (30 sept 23:00:00) is obviously due to
> > a timezone-daylight saving issue.
Fixed in current sources by using mktime() rather than by rotating the
date to 12 noon to try to get the correct time zone (didn't work around
daylight savings time).
> Thomas Lockhart is our lead g
[EMAIL PROTECTED] writes:
> Tom Lane wrote:
>> 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.
> postgres, I would tend to think...
> For one thing I've just found out: the 'histeresis' effect occurs
> only
Tom Lane wrote:
>> Timezone is set to America/Buenos Aires
>> Changing this seems to elliminate the bug.
> What did you change it *to*, exactly? And what dates did you test
> after changing?
I changed to "Etc/GMT+4" and tested the same just the same dates
>
Edward Q
[EMAIL PROTECTED] 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:0
for what it's worth, when i run these two tests, i
get the correct results
i'm using RedHat 6.2 also.
here are more details:
[ebridges@sleeepy]$ uname -a
Linux sleeepy 2.2.16 #2 SMP Mon Jul 31 14:51:33 EDT 2000 i686 unknown
[ebridges@sleeepy]$ psql -V
psql (PostgreSQL) 7.0.2
Portions Copyright
[EMAIL PROTECTED] writes:
> Timezone is set to America/Buenos Aires
> Changing this seems to elliminate the bug.
What did you change it *to*, exactly? And what dates did you test
after changing?
I would expect the bug to follow the DST transition date, which varies
in different timezones. Als
Well, I've tracked down the problem to its
mininal form, I think:
Here it goes:
[postgres@bert postgres]$ createdb test5
CREATE DATABASE
[postgres@bert postgres]$ psql test5
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with
