From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Pete Forman <pete(dot)forman(at)westerngeco(dot)com> |
Cc: | lockhart(at)fourpalms(dot)org, Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: AW: Re: tinterval - operator problems on AIX |
Date: | 2001-01-12 15:54:43 |
Message-ID: | 3A5F28C3.FCBDC208@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-01-12 15:55:48 | Re: AW: AW: Re: tinterval - operator problems on AIX |
Previous Message | Zeugswetter Andreas SB | 2001-01-12 15:51:51 | AW: AW: Re: tinterval - operator problems on AIX |