Rasmus Resen Amossen wrote:
> There has been quite a few mails on the misoperation in date values
> before the epoc on RH7.3 and pgsql7.2.1 (something with glibc).
>
> Is this bug fixed? If yes: How can I achive this fix?
No, no fix yet. We had hoped that since May glibc folks would have
addressed it, but it seems not. We are left working around it
ourselves.
> If not: How can I make postgresql work on RH7.3?
You need a patch which we will have to develop.
>
> Shouldn't the FAQ mention the issue and a workaround?
No, we are not in the habit of making an FAQ entry when every vendor
decides to ship broken software. It takes a lot of requests to make an
FAQ.
> If some should be a bit confused: The error appears when operating on
> dates before the epoc:
>
> rhklan=> create table test(day date);
> CREATE
> rhklan=> insert into test values('1969-2-2');
> INSERT 824159 1
> rhklan=> select age(now(),day) from test;
> ERROR: Unable to convert date to tm
Yep, thread of discussion is:
http://fts.postgresql.org/db/mw/index.html?section=-1&word=Redhat+7.3+time+manipulation+bug&action=Search&sdb_d=7&sdb_m=5&sdb_y=2002&sde_d=8&sde_m=7&sde_y=2002&weight=0&format=0&order=1
I am not in favor of shipping a timezone database with PostgreSQL, and
even if we did, it wouldn't match the OS's database. I think a good
solution is to gab mktime() from glibc, fix the bug, add that code to
our sourcetree (is LGPL) and put the fixed version earlier in the link
line so it is used instead of glibc's mktime.
As you can imagine, it is kind of a strange thing to do, so we are not
rushing to do it, but such a solution may be required soon.
Right now, the only solution I have for you it to complain to your
vendor about mktime in glibc and get a fix from them.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026