Re: [HACKERS] Date/time on glibc2 linux
От | Oleg Broytmann |
---|---|
Тема | Re: [HACKERS] Date/time on glibc2 linux |
Дата | |
Msg-id | Pine.SOL2.3.96.SK.981204185723.24083P-100000@sun.med.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] Date/time on glibc2 linux ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: