Re: AW: Re: tinterval - operator problems on AIX
От | Thomas Lockhart |
---|---|
Тема | Re: AW: Re: tinterval - operator problems on AIX |
Дата | |
Msg-id | 3A5F28C3.FCBDC208@alumni.caltech.edu обсуждение исходный текст |
Ответ на | AW: Re: tinterval - operator problems on AIX (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Список | 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 по дате отправления: