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

In response to

Browse pgsql-hackers by date

  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