Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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: regression.diffs
Description: text/plain (24.4 KB)

In response to

Responses

pgsql-bugs by date

Next:From: Thomas LockhartDate: 2002-04-11 14:33:34
Subject: Re: Bug #630: date/time storage problem: timestamp parsed
Previous:From: renaud diezDate: 2002-04-11 09:33:34
Subject: problem with mandrake 8.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group