Thread: nasty problem with redhat 6.2 + pg 7.02
After more than two years of using postgresql with linux, this
may turn to be my last frustration; not being able to find the
problem, and with several thousands of customers that must pay
on the FIRST day of each month, I find this NASTY; must I
turn to oracle on solaris, I wonder....
Take a look at this: if you can't spot the problem,
(I couldn't) at least you should be warned: this
seems pretty serious.
(using PGDATESTYLE=Postgres )
[postgres@ren postgres]$ createdb test1
CREATE DATABASE
[postgres@ren postgres]$ echo "create table serv2 (fecha1 date,fecha2 date);" |
psql test1
CREATE
[postgres@ren postgres]$ echo "insert into serv2 values
('13-01-2000','01-10-2000');"| psql test1
INSERT 380928512 1
[postgres@ren postgres]$ echo "select * from serv2;" | psql test1
fecha1 | fecha2
------------+------------
13-01-2000 | 30-09-2000
(1 row)
?????? What's happening here ???
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
The problem is rather random; (for some reason, it happens with less
'probability' :-((( if I create the table with only a field date2)
I'm using RedHat 6.2 (having suffered recently the horrible 'sort -n'
bug http://www.redhat.com/support/errata/RHBA-2000-040-01.html
I'm having less and less confidence on this platform... but...)
Actually, I could reproduce the problem in other rh 6.2 machine, but
it does not appears with another machine running RH 6.1
BUT, the problem does not reveal on another machine, which has rh 6.2
(but pg was compiled over the previous rh 6.1 distro... could that
make any difference)?
Yes, I run the (complete) regression tests. All OK.
More data follows below...
Hernan Gonzalez
Buenos Aires, Argentina
hgonzal@sinectis.com.ar
##########################################################################
[postgres@ren postgres]$ uname -a
Linux ren.sinectis.com.ar 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000
i686 unknown
[postgres@ren postgres]$ cat /etc/redhat-release
Red Hat Linux release 6.2 (Zoot)
[postgres@ren postgres]$ echo "select version();" | psql test1
version
---------------------------------------------------------------------
PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66
(1 row)
[postgres@ren postgres]$ set (stripped)
HOSTTYPE=i386
LANG=en_US
LOGNAME=postgres
OSTYPE=Linux
PATH=/bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/X11R6/bin:/home/postgres/bin:/sql/bin:
PGDATA=/sql/data
PGDATESTYLE=Postgres
PGLIB=/sql/lib
HOME=/home/postgres
HOSTTYPE=i386
UID=500
USER=postgres
USERNAME=
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:
test=# SET datestyle=postgres;
SET VARIABLE
test=# create table serv2 (fecha1 date, fecha2 date);
CREATE
test=# insert into serv2 values ('13-01-2000','01-10-2000');
INSERT 407754 1
test=# select * from serv2;
fecha1 | fecha2
------------+------------
01-13-2000 | 01-10-2000
(1 row)
test=#
System is RedHat 6.2 with the PostgreSQL 7.0.2-2 RPMset loaded. Hmmm,
but 13-01-2000 got flipped to 01-13-2000, and 01-10-2000 didn't flip...
Now that is strange.
Let's try something...
test=# delete from serv2;
DELETE 1
test=# insert into serv2 values ('10-01-2000','01-10-2000');
INSERT 407765 1
test=# select * from serv2;
fecha1 | fecha2
------------+------------
10-01-2000 | 01-10-2000
(1 row)
Nope, still right.
Hmmm, if I insert '30-09-2000', I get:
test=# select * from serv2;
fecha1 | fecha2
------------+------------
01-13-2000 | 09-30-2000
(1 row)
Now, this is with DATESTYLE set within the psql session using 'set
datestyle' -- let's try the PGDATESTYLE variable...
[lowen@utility www]$ export PGDATESTYLE=Postgres
[lowen@utility www]$ psql -c "delete from serv2" test
DELETE 1
[lowen@utility www]$ psql -c "insert into serv2 values
('13-01-2000','01-10-2000')" test
INSERT 407808 1
[lowen@utility www]$ psql -c "select * from serv2" test
fecha1 | fecha2
------------+------------
01-13-2000 | 01-10-2000
(1 row)
[lowen@utility www]$
Still the same results as earlier.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Leon -
I can't reproduce this with 7.0.2 on a Debian install, but it smacks
of a timezone problem of some sort. Do you have any other environment
variables set that might affect the interpretation of date/time info?
Note that you've shown us the environment your running the _client_
in. What does the _server_ have set in it's environment? I'm not sure
about RedHat: on Debian, it's set in /etc/postgresql/postgresql.env
Note that I had
to explicitly set "European" to get output that matched yours: just using
"postgres" used US conventions.
Here's my transcript:
test=# create table serv2 (fecha1 date,fecha2 date);
CREATE
test=# insert into serv2 values ('13-01-2000','01-10-2000');
INSERT 712438 1
test=# set datestyle = European;
SET VARIABLE
test=# set datestyle = postgres;
SET VARIABLE
test=# show datestyle;
NOTICE: DateStyle is Postgres with European conventions
SHOW VARIABLE
test=# insert into serv2 values ('13-01-2000','01-10-2000');
INSERT 712439 1
test=# select * from serv2;
fecha1 | fecha2
------------+------------
13-01-2000 | 01-10-2000
13-01-2000 | 01-10-2000
(2 rows)
test=# select version();
version
---------------------------------------------------------------
PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc 2.95.2
(1 row)
test=#
Ross
On Tue, Sep 19, 2000 at 11:37:52AM -0300, leonbloy@sinectis.com.ar wrote:
> After more than two years of using postgresql with linux, this
> may turn to be my last frustration; not being able to find the
> problem, and with several thousands of customers that must pay
> on the FIRST day of each month, I find this NASTY; must I
> turn to oracle on solaris, I wonder....
>
> Take a look at this: if you can't spot the problem,
> (I couldn't) at least you should be warned: this
> seems pretty serious.
>
> (using PGDATESTYLE=Postgres )
>
>
> [postgres@ren postgres]$ createdb test1
> CREATE DATABASE
> [postgres@ren postgres]$ echo "create table serv2 (fecha1 date,fecha2 date);" |
> psql test1
> CREATE
> [postgres@ren postgres]$ echo "insert into serv2 values
> ('13-01-2000','01-10-2000');"| psql test1
> INSERT 380928512 1
> [postgres@ren postgres]$ echo "select * from serv2;" | psql test1
> fecha1 | fecha2
> ------------+------------
> 13-01-2000 | 30-09-2000
> (1 row)
>
>
> ?????? What's happening here ???
>
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
On Tue, Sep 19, 2000 at 12:36:22PM -0400, Lamar Owen wrote:
>
> I can't duplicate:
> test=# SET datestyle=postgres;
> SET VARIABLE
> test=# create table serv2 (fecha1 date, fecha2 date);
> CREATE
> test=# insert into serv2 values ('13-01-2000','01-10-2000');
> INSERT 407754 1
> test=# select * from serv2;
> fecha1 | fecha2
> ------------+------------
> 01-13-2000 | 01-10-2000
> (1 row)
>
> test=#
> System is RedHat 6.2 with the PostgreSQL 7.0.2-2 RPMset loaded. Hmmm,
> but 13-01-2000 got flipped to 01-13-2000, and 01-10-2000 didn't flip...
> Now that is strange.
Right: Lamar, you're using US conventions. Leon appears to be using
European. One of the postgresql 'features' is that it will try hard to
parse dates, even using the other convention if necessary. There is no
13th month, so the first one got taken directly. The 10th of January, on
the other hand...
This looks suspiciously like a timezone/daylight savings time issue, to
me. Somewhere, the date is getting represented as a full date/time, then
an hour is getting subtracted, then truncated to a date again.
Leon, try something like:
INSERT INTO serv2 VALUES ('13-01-2000'::date,'01-10-2000'::date);
That _might_ force the correct conversion, but I cant' test it, since
I don't see your problem here.
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
> On Tue, Sep 19, 2000 at 12:36:22PM -0400, Lamar Owen wrote:
> >
> > I can't duplicate:
> > test=# SET datestyle=postgres;
> > SET VARIABLE
> > test=# create table serv2 (fecha1 date, fecha2 date);
> > CREATE
> > test=# insert into serv2 values ('13-01-2000','01-10-2000');
> > INSERT 407754 1
> > test=# select * from serv2;
> > fecha1 | fecha2
> > ------------+------------
> > 01-13-2000 | 01-10-2000
> > (1 row)
> >
> > test=#
> > System is RedHat 6.2 with the PostgreSQL 7.0.2-2 RPMset loaded. Hmmm,
Right. I tried on a machine with the RPM set, and all went OK.
My problem appears with a compiled 7.02 distro (no special switches,
no locales)
>
> This looks suspiciously like a timezone/daylight savings time issue, to
> me. Somewhere, the date is getting represented as a full date/time, then
> an hour is getting subtracted, then truncated to a date again.
>
> INSERT INTO serv2 VALUES ('13-01-2000'::date,'01-10-2000'::date);
>
> That _might_ force the correct conversion, but I cant' test it, since
> I don't see your problem here.
>
No luck:
test1=# create table servx (fechax date);
CREATE
test1=# insert into servx values ('01-10-2000');
INSERT 81748516 1
test1=# select * from servx;
fechax
------------
30-09-2000
(1 row)
test1=# insert into servx values ('01-10-2000'::date);
INSERT 81748517 1
test1=# select * from servx;
fechax
------------
30-09-2000
30-09-2000
(2 rows)
And (to make things worse) the result is rather random:
On the same machine, I start another db ...
[postgres@bert postgres]$ createdb test2
CREATE DATABASE
[postgres@bert postgres]$ psql test2
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
test2=# create table servx (fechax date);
CREATE
test2=# insert into servx values ('01-10-2000');
INSERT 81748585 1
test2=# select * from servx;
fechax
------------
01-10-2000
(1 row)
test2=# insert into servx values ('01-10-2000'::date);
INSERT 81748586 1
test2=# select * from servx;
fechax
------------
01-10-2000
01-10-2000
(2 rows)
test2=# create table servxx (fechax date,fechaxx date);
CREATE
test2=# insert into servxx values ('01-10-2000','01-10-2000');
INSERT 81748597 1
test2=# select * from servxx;
fechax | fechaxx
------------+------------
01-10-2000 | 01-10-2000
(1 row)
test2=# insert into servxx values ('13-10-2000','01-10-2000');
INSERT 81748598 1
test2=# select * from servxx;
fechax | fechaxx
------------+------------
01-10-2000 | 01-10-2000
13-10-2000 | 30-09-2000
Aaggghhh!!!!
Thanks, anyway
Hernan Gonzalez
Argentina
On Tue, 19 Sep 2000, Lamar Owen wrote: > I can't duplicate: > test=# SET datestyle=postgres; Me neither and I didn't set the datestyle - based on your RPM set. Rod -- Roderick A. Anderson raanders@altoplanos.net Altoplanos Information Systems, Inc. Voice: 208.765.6149 212 S. 11th Street, Suite 5 FAX: 208.664.5299 Coeur d'Alene, ID 83814
> > On Tue, Sep 19, 2000 at 12:36:22PM -0400, Lamar Owen wrote: > > This looks suspiciously like a timezone/daylight savings time issue, to > > me. Somewhere, the date is getting represented as a full date/time, then > > an hour is getting subtracted, then truncated to a date again. > > Yes, it's certainly that kind of issue. I tried changing my timezone (I was using America/Buenos Aires) and the problem seems to disappear. But... why ? how ? what?? Who is to blame ? RedHat, linux or postgres ? In any case, this should never afect a 'date' type field! Cheers Hernan Gonzalez Buenos Aires, Argentina
Sorry for the verbosity, but I forgot to answer this one: > Leon - > I can't reproduce this with 7.0.2 on a Debian install, but it smacks > of a timezone problem of some sort. Do you have any other environment > variables set that might affect the interpretation of date/time info? > Timezone is set to America/Buenos Aires Changing this seems to elliminate the bug. > Note that you've shown us the environment your running the _client_ > in. What does the _server_ have set in it's environment? I'm not sure > about RedHat: on Debian, it's set in /etc/postgresql/postgresql.env > The example I posted was run on the server. I.e., the settings are those of the server AND the client Thanx Hernan Gonzalez Argentina
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
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 SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
test5=# select '01-10-2000'::date;
?column?
------------
01-10-2000
(1 row)
test5=# select '13-10-2000'::date;
?column?
------------
13-10-2000
(1 row)
test5=# select '01-10-2000'::date;
?column?
------------
30-09-2000
(1 row)
Strange, isnt' it ?
Also:
[postgres@bert postgres]$ createdb test6
CREATE DATABASE
[postgres@bert postgres]$ psql test6
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
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.
Cheers
Hernan
leonbloy@sinectis.com.ar 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. Also, since it's the spring-forward transition
where you can see the problem, for zones north of the equator you'd be
needing to check the March-ish transition date not the October-ish one.
In my experience, timekeeping routines often have to distinguish between
northern and southern timezones in order to do DST properly. It could
be that you're looking at some bug in RedHat 6.2's libc that only
manifests for southern timezones. If so that might explain why the
rest of us haven't seen it.
regards, tom lane
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 (c) 1996-2000, PostgreSQL, Inc . . . i compiled/installed postgres from a tarball. are you using the RPM? or did you compile from scratch? if the former, perhaps it's a bug in the redhat binary rpm. HTH --e-- On Tue, 19 Sep 2000 15:44:15 -0300, leonbloy@sinectis.com.ar wrote: > 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 SQL commands > \? for help on internal slash commands > \g or terminate with semicolon to execute query > \q to quit > > test5=# select '01-10-2000'::date; > ?column? > ------------ > 01-10-2000 > (1 row) > > test5=# select '13-10-2000'::date; > ?column? > ------------ > 13-10-2000 > (1 row) > > test5=# select '01-10-2000'::date; > ?column? > ------------ > 30-09-2000 > (1 row) > > Strange, isnt' it ? > Also: > > [postgres@bert postgres]$ createdb test6 > CREATE DATABASE > [postgres@bert postgres]$ psql test6 > Welcome to psql, the PostgreSQL interactive terminal. > > Type: \copyright for distribution terms > \h for help with SQL commands > \? for help on internal slash commands > \g or terminate with semicolon to execute query > \q to quit > > 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. > > Cheers > > Hernan > > >
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
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. Bridges wrote:
>i compiled/installed postgres from a tarball. are you
> using the RPM? or did you compile from scratch?
I compiled the sources too.
>>>>>>>>>>>>>
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 WITHIN A CONNECTION:
If I run this script:
####################################
# !/usr/bin/perl
use DBI;
$host = 'localhost'; $db = 'test5';
my $db1;
$db1 = DBI->connect("dbi:Pg:dbname=$db; host=$host;port=5432",'postgres','');
doit('01-10-2000');
doit('13-10-2000');
doit('01-10-2000');
sub doit
{
my($fecha)=@_;
my $sth = $db1->prepare("SELECT '$fecha'::date::timestamp");
my $rv = $sth->execute;
my ($x)=$sth->fetchrow_array;
print "$fecha => $x\n";
}
#####################################3
I get:
[postgres@bert postgres]$ perl pru.pl
01-10-2000 => Sat 30 Sep 23:00:00 2000 ART
13-10-2000 => Fri 13 Oct 00:00:00 2000 ARST
01-10-2000 => Sat 30 Sep 00:00:00 2000 ART
[postgres@bert postgres]$
If I intermix a disconnect/connect between the calls to doit()
I get:
[postgres@bert postgres]$ perl pru.pl
01-10-2000 => Sat 30 Sep 23:00:00 2000 ART
13-10-2000 => Fri 13 Oct 00:00:00 2000 ARST
01-10-2000 => Sat 30 Sep 23:00:00 2000 ART
[postgres@bert postgres]$
By the way, on another redhat 6.1 machine
(fortunately, my postgres producion server)
with the same timezone, the results are just right:
[postgres@crisol postgres]$ perl pru.pl
01-10-2000 => Sun 01 Oct 00:00:00 2000 ART
13-10-2000 => Fri 13 Oct 00:00:00 2000 ART
01-10-2000 => Sun 01 Oct 00:00:00 2000 ART
This is getting a little boring for the rest of the list,
i suppose... should I send this to the hackers list? or
mail it privately ?
Regards.
Hernan Gonzalez
Argentina
leonbloy@sinectis.com.ar 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 WITHIN A CONNECTION:
Doesn't prove a thing. The libc state I'm thinking of would be
recomputed on first use within a given process, ie, per backend.
So we still have no idea if the problem is libc's or Postgres'.
Given that the problem seems to be specific to your timezone,
and Postgres itself knows very little about timezones, a libc bug
is well within the realm of possibility.
Is anyone else able to reproduce this misbehavior at a DST boundary?
regards, tom lane
> > 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 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?
Hmm, didn't see the thread (I unsubscribed from -general due to mailing
list overload).
And I don't yet see the problem on my machine:
setenv PGTZ America/Buenos_Aires
lockhart=# set datestyle='postgres,european';
lockhart=# select '01-10-2000'::date::timestamp;
Sun 01 Oct 00:00:00 2000 ART
lockhart=# select '13-10-2000'::date::timestamp;
Fri 13 Oct 00:00:00 2000 ART
lockhart=# select '01-10-2000'::date::timestamp;
Sun 01 Oct 00:00:00 2000 ART
lockhart=# select version();
PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc 2.95.3
This is on a Mandrake 7.1 box with RPMs built from Lamar's source RPMs.
Can someone else reproduce the problem on a RedHat 6.2 box?
- Thomas