From: | Reinhard Max <max(at)suse(dot)de> |
---|---|
To: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
Cc: | Sean Chittenden <sean(at)chittenden(dot)org>, <pgsql-bugs(at)postgresql(dot)org>, Andreas Jaeger <aj(at)suse(dot)de> |
Subject: | Re: Bug #630: date/time storage problem: timestamp parsed |
Date: | 2002-04-11 12:55:45 |
Message-ID: | Pine.LNX.4.44L0.0204111400140.8293-200000@wotan.suse.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
Attachment | Content-Type | Size |
---|---|---|
regression.diffs | text/plain | 24.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2002-04-11 14:33:34 | Re: Bug #630: date/time storage problem: timestamp parsed |
Previous Message | renaud diez | 2002-04-11 09:33:34 | problem with mandrake 8.2 |