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

From: Andreas Schwab <schwab(at)suse(dot)de>
To: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
Cc: Reinhard Max <max(at)suse(dot)de>
Subject: Re: Bug #630: date/time storage problem: timestamp parsed
Date: 2002-04-11 15:17:50
Message-ID: jen0wa1cyp.fsf@sykes.suse.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:

|> > > 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
|> > 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").
|>
|> ??!! I'm sorry that I don't remember the exact context here (didn't this
|> thread start on a FreeBSD amchine?), but are you saying that glibc
|> shipped with Linux will potentially stop supporting times and time zones
|> before 1970?
|>
|> Standard or not, there is a *long* history of all decent implementations
|> supporting dates prior to 1970, and platforms which do not do so (AIX?)
|> have always been a source of scorn and derision. Really.

This is the bug report against glibc that prompted the change:

http://bugs.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=default&pr=2738

|> Ah, but this might explain why I've always seen on my Linux box a 1
|> second offset returned from mktime() for dates before 1970. Everything
|> is shifted to allow -1 to be a special value I'll bet...

This is a joke, isn't it?

|> Yikes. That is not currently acceptable (most platforms deployed in the
|> world *do* handle dates and times before 1970), but if I'm understanding
|> things correctly we will need to somehow reimplement the entire time and
|> time zone support system within PostgreSQL. I'll start looking at the
|> FreeBSD code to see what is available. *sigh*

Since POSIX says years before 1970 are undefined, it seems you are right.

Andreas.

--
Andreas Schwab, SuSE Labs, schwab(at)suse(dot)de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Thomas Lockhart 2002-04-11 15:59:58 Re: Bug #630: date/time storage problem: timestamp parsed
Previous Message Thomas Lockhart 2002-04-11 14:33:34 Re: Bug #630: date/time storage problem: timestamp parsed