Re: Bug #630: date/time storage problem: timestamp parsed - Mailing list pgsql-bugs

From Reinhard Max
Subject Re: Bug #630: date/time storage problem: timestamp parsed
Date
Msg-id Pine.LNX.4.44L0.0204111400140.8293-200000@wotan.suse.de
Whole thread Raw
In response to Re: Bug #630: date/time storage problem: timestamp parsed  (Thomas Lockhart <lockhart@fourpalms.org>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Bug #631: pg_dumpall does not accept -F or -f
Next
From: Thomas Lockhart
Date:
Subject: Re: Bug #630: date/time storage problem: timestamp parsed