Re: Bug #630: date/time storage problem: timestamp parsed

Поиск
Список
Период
Сортировка
От Reinhard Max
Тема Re: Bug #630: date/time storage problem: timestamp parsed
Дата
Msg-id Pine.LNX.4.44L0.0204111400140.8293-200000@wotan.suse.de
обсуждение исходный текст
Ответ на Re: Bug #630: date/time storage problem: timestamp parsed  (Thomas Lockhart <lockhart@fourpalms.org>)
Список pgsql-bugs
Hi,

On Tue, 9 Apr 2002 at 19:43, Thomas Lockhart wrote:

> I don't think that our code checks explicitly for a "-1" return, since
> the range is checked just before the call, but it would probably be a
> good idea if it did

Indeed.

As I noticd yesterday, glibc's mktime() has in the current snapshot
been changed to return -1 for dates before the epoch. Our glibc guru
(Cc'ed) told me, this is according to the standards (C and POSIX)
which say, that time_t is undefined for dates prior the epoch, which
to me seems obvoius, because otherwise the error return couldn't be
distinguished from the time_t value "one second before the epoch").

This change causes some of the regression tests to fail ('abstime',
'tinterval', and 'horology'). All failures occur on dates that are
given in PST, lay between 1900 and 1970, and show a difference of 8
hour (regression.diffs attached).

I've added code to DetermineLocalTimeZone that elogs and ERROR if
mktime returns < 0, which showed, that this also happens in some other
tests, but without affecting the results there (maybe pure luck?).

cu
    Reinhard

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Bug #631: pg_dumpall does not accept -F or -f
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Re: Bug #630: date/time storage problem: timestamp parsed