
> > > > 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

Thu, 11 Jan 2001 10:04:54 +0100
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at>
AW: AW: AW: Re: tinterval - operator problems on AIX
> 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 hour off, Solaris or Linux.

Yes, I've seen this before. As I mentioned, Solaris does a particularly
good job of including the variations in DST definitions around WWII and
earlier. In the US, there are several different conventions used in
those years, presumably based on a need for energy conservation and
perhaps to maximize production efficiency.

> This raises another issue. Why do we distribute expected files with bogus results
> in them?

It depends on what you mean by "bogus". imho we should (and do)
distribute "expected" files which reflect the results expected for a
particular machine -- based on a careful analysis of the results from
that machine from an expert, such as you are doing with AIX. Your
results are incremental differences from some other "standard machine",
which has also been carefully analyzed. By definition, the "standard
machine" has been and is a Linux box, for the simple historical reason
that this was my machine at the time that scrappy and I resurrected the
regression tests several years ago. But it is a good choice for the
standard, since that style of machine has a large installed base and the
cost of entry for someone else wanting to participate is very low.

If I understand the alternatives you are considering, the other choice
is to distribute "expected" files which reflect what we think a machine
should produce if it behaved the way we think it should. That doesn't
really help anyone, since a tester would have to derive from first
principles the correctness of the test results each time they run the
test.

Instead, we document the current behavior, and the regression tests can
now catch *changes* in behavior, to be analyzed just as you are doing.
If AIX fixes their mktime() and timezone behavior, you (or someone else
running AIX) will see it, evaluate it, and adjust the regression
"expected" files to reflect this.

                         - Thomas

Thu, 11 Jan 2001 15:19:42 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: AW: AW: AW: Re: tinterval - operator problems on AIX