Hello!
On Fri, 4 Dec 1998, Thomas G. Lockhart wrote:
> This isn't specific to your timezone; I see the same problem with
> PST8PST. The routine actually getting invoked is date_datetime() in
> backend/utils/adt/datetime.c. I would be reluctant to scatter
> glibc2-specific bug-fix code throughout the date/time files (the issue
> has come up before), but once we've identified the actual cause of the
> problem we can consider a workaround.
I was pretty sure the problem is not with my timezone. The actual cause
of the problem is very simple - glibc2 has invalid timezone/tzname even
after tzset(). To my surprise, strftime() works right! It looks like
glibc2 has two different tzname's - public and internal. Because of this
ALL date/time arithmetic will fail sooner or later. The code I stole from python and displayed yesterday works around
the
problem. It seems python's configure can safely detect this and avoid. I
asked python author about this. Waiting for replay...
> btw, can you see a problem in the regression tests? I wonder if there
> are other date/time routines which show problems. I don't usually run
> Postgres regression tests on my RH5.1 box since that is at work...
Regression test passed Ok on datetime, abstime, reltime, tinterval tests
on Debian 2.0. That is - the error is not triggered. Should we change the
regression test?
Oleg.
---- Oleg Broytmann National Research Surgery Centre http://sun.med.ru/~phd/ Programmers don't die, they
justGOSUB without RETURN.