On Friday 10 May 2002 09:55 am, Thomas Lockhart wrote:
> Ooh. Maybe the SuSE folks who were working on glibc actually changed it
> the way they were talking about. Here (may be) the issue:
> 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.
Well, I went to bat for this a little bit ago, relating to a bug report, but
I've struck out. The ISO C standard spells it out plainly that dates before
1970 are just simply illegal for mktime and friends. So, glibc was aligned
with the ISO standard (available online -- see my link in the post regarding
the mktime bug in Red Hat 7.3). This will change ALL newer Linux
distributions, and thus we need to correct our usage, as the glibc people are
not likely to change -- in fact, they will likely say that our code is
broken.
> Any suggestions on how to pursue this??
What information do we need?
Frankly, relying on a side-effect of a call in this way is our bug. Sorry.
It was a neat hack, but it now is broken. Where is this in the tree? I can
take a look at it if no one else wants to.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11