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

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Pete Forman <pete(dot)forman(at)westerngeco(dot)com>
Cc: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: AW: Re: tinterval - operator problems on AIX
Date: 2001-01-11 15:31:24
Message-ID: 3A5DD1CC.4E645A4D@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> FWIW, that should be to add 28*n to tm_year and subtract (365*4+1)*7
> *24*60*60*n from the time_t returned. That calculates tm_wday
> correctly.
> Also I should have been more explicit that this applies only to AIX
> and IRIX. Those return -1 from mktime(year < 1970) and do not allow
> DST rules to vary from year to year. Linux and Solaris have more
> capable date libraries.

Oh, so AIX and IRIX have just one-line time zone databases? Yuck.

How about having some #if BROKEN_TIMEZONE_DATABASE code which uses both
mktime() and localtime() to derive the correct time zone? That is, call
mktime to get a time_t, then call localtime() to get the time zone info,
but only on platforms which do not get a complete result from just the
call to mktime(). In fact, we *could* check for tm->tm_isdst coming back
"-1" for every platform, then call localtime() to make a last stab at
getting a good value.

Comments?

- Thomas

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2001-01-11 15:32:13 Re: UNDER?
Previous Message Thomas Lockhart 2001-01-11 15:19:42 Re: AW: AW: AW: Re: tinterval - operator problems on AIX