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

From Thomas Lockhart
Subject Re: AW: Re: tinterval - operator problems on AIX
Date
Msg-id 3A5F28C3.FCBDC208@alumni.caltech.edu
Whole thread Raw
In response to AW: Re: tinterval - operator problems on AIX  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
List pgsql-hackers
> As far as AIX and IRIX are concerned the timezones _are_ the same.  No
> variation of rules from year to year is possible.  You are not going
> to work out DST rules for earlier years without incorporating third
> party libraries.  As I understand it PostgreSQL undertakes to
> calculate dates only as accurately as the underlying OS allows.

Yes. Hence my reluctance to have code which does time-shifting to get
time zones for all platforms. Perhaps it could/should be a configure
test? And then we can have a "HAVE_SIMPLISTIC_TZ" (or whatever) #define
in the code to enable hacks around the problem? 

The concern led to my suggestion that we should omit timezone fields
from output -- basically do the equivalent of pre-1901 handling using
GMT -- if DST is not resolved correctly (but I'm still not sure if this
will pan out).

>  > I'll have to look at the ramifications for input times and for
>  > dump/restore operations. Does you system respect the TZ or PGTZ
>  > environment variable?
> My code uses localtime and mktime which depend on TZ.  There is no
> dependency on PGTZ, unless somewhere else in postgres there is an
> equivalent of setenv(TZ=getenv(PGTZ)).

Yes there is.
                  - Thomas


pgsql-hackers by date:

Previous
From: Zeugswetter Andreas SB
Date:
Subject: AW: AW: Re: tinterval - operator problems on AIX
Next
From: Tom Lane
Date:
Subject: Re: AW: AW: Re: tinterval - operator problems on AIX