...
> This isn't the case you've indicated... This is the regression test diff
> output:
> *** ./expected/abstime.out Wed Nov 21 19:27:25 2001
> --- ./results/abstime.out Thu May 9 17:27:00 2002
> ! | Sat May 10 23:59:12 1947 PST
...
> ! | Sat May 10 15:59:12 1947 PST
...
> As you can see the time is different not the time/date format...
Ooh. Maybe the SuSE folks who were working on glibc actually changed it
the way they were talking about. Here (may be) the issue:
Posix demands that mktime() and friends return -1 on error or on "unable
to convert time". Traditionally, many implementations (AIX was a notable
exception, adding to its rep as a brain-damaged system) ignored that
restriction, willingly converting for times before 1970, and returning a
negative number. And timezone databases supported times before 1970, and
the world was happy.
But that Posix requirement made it difficult to support the time "one
second before 1970", which happens to be "-1". So the idea was to start
returning -1 for any time before 1970. That sucks. But for PostgreSQL,
we actually don't use the results of mktime(), but we *do* use a
side-effect of the call, which fills in the time zone information (and a
few other fields) in the structures given to mktime() as *input*. We
currently ignore the status return of mktime(), since we guard against
illegal calling parameters another way.
I would be very happy if the implementation of mktime() continued to
*properly* fill in these fields, even though it insists on returning an
error condition for dates before 1970. As it is (assuming that a change
actually has occurred) the timezone system in GNU systems has been badly
and gratuitously damaged in the newest releases of glibc.
Any suggestions on how to pursue this??
- Thomas
