> The other category is run-time behaviour, which is the present case of
> testing whether mktime() behaves a certain way when given certain
> arguments. Another item that has been thrown around over the years is
> whether the system supports Unix domain sockets (essentially a run-time
> behavio
> > I agree that configure is the way to go. What if someone has
> > installed a third party library to provide a better mktime() and
> > localtime()?
>
> Exactly. What if someone has a binary PostgreSQL package installed, then
> updates his time library to something supposedly binary compatib
> > The correct thing to do instead of the #if defined (_AIX) would be to use
> > something like #ifdef NO_NEGATIVE_MKTIME and set that with a configure.
> > Thomas, are you volunteering ?
>
> Actually, I can volunteer to be supportive of your efforts ;) I'm
> traveling at the moment, and don't
> > As I see it, the Linux results are also not 100 % correct
> in respect to dates
> > before 1970. (based on assumption that Solaris is correct)
> > <| Sat May 10 23:59:12 1947 PST
> > >| Sat May 10 23:59:12 1947 PDT
> > Was 1947 PDT or PST ? In eighter case one result is one h
