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

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

In response to

Responses

Browse pgsql-bugs by date

  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