Re: AW: AW: Re: tinterval - operator problems on AIX - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: AW: AW: Re: tinterval - operator problems on AIX
Date
Msg-id 3A5D256F.4C0C814B@alumni.caltech.edu
Whole thread Raw
In response to AW: AW: Re: tinterval - operator problems on AIX  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
List pgsql-hackers
> > > 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? 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?

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

Seriously, not that I know of. The problem is that there is no API for
accessing time zone info other than the localtime()/mktime() kinds of
calls, so we are stuck using that (or stuck repackaging something like
zinc into Postgres directly, which afaik is not anything we would be
interested in doing).
                     - Thomas


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: BETWEEN [SYMMETRIC | ASYMMETRIC]
Next
From: Thomas Lockhart
Date:
Subject: Re: Interesting CERT advisory