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