AW: AW: AW: Re: tinterval - operator problems on AIX

> > > > On AIX mktime(3) leaves tm_isdst at -1 if it does not have timezone
> > > > info for that particular year and returns -1.
> > > > The following code then makes savings time out of the -1.
> > > > tz = (tm->tm_isdst ? (timezone - 3600) : timezone);
> > > Hmm. That description is consistant with what I see in the Linux man
> > > page. So I should check for (tm->tm_isdst > 0) rather than
> > > checking for non-zero?
> > It is obviously not possible to determine tm_isdst with mktime for a
> > negative time_t. Thus with above fix PST works, but PDT is then busted :-(
>
> Obvious to AIX only?
Yes. The whole subject only concerns AIX (at least so far).
> My conclusion is that the AIX timezone database is
> damaged or missing for pre-1970 dates, but that other systems bothered
> to get it at least somewhat right. Is there another issue here that I'm
> missing?

The tz db is neighter damaged nor missing anything (see below). Only mktime
does not work for some (maybe even avoidable) reason for dates before 1970.

> > localtime does convert a negative time_t correctly including dst.
> > Is there another way to determine tm_isdst ?
>
> Yes. Replace AIX with Linux or something else, then recompile Postgres
> ;)

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)

e.g.:
1503c1503
< | 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 hour off, Solaris or Linux.

This raises another issue. Why do we distribute expected files with bogus results
in them ? Imho it would be better to only have expected files for rounding issues and
the like. Else the user feels that horology works fine on his machine, but as it looks it only
works on a few.

Andreas