> > 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.
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 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).
Sure.
> 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?).
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*
- Thomas