| 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 14:54:57 |
| Message-ID: | 3A5F1AC1.38259F5F@alumni.caltech.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Here is the program. The call to localtime(&t_ago) is redundant and
> hence the adjustment of t_ago can be skipped. It is in this program
> as a sanity check.
> As it stands, this program assumes that the input and resulting date
> are in the usual UNIX range of [1901, 2038]. I presume that there is
> code in place that checks the range of dates.
Interesting idea. I'm not sure that assuming that timezones from 1943
are the same as timezones from 2013 (they are not, at least in the US)
is any more valid than just accepting the result from your system. I'd
like to explore more possibilities before we settle on a solution.
Perhaps I should just add checks to assume an unspecified time zone wrt
output formatting if the tm_isdst flag comes back as "-1"?
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?
- Thomas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-01-12 15:02:56 | Re: AW: Re: GiST for 7.1 !! |
| Previous Message | Oleg Bartunov | 2001-01-12 14:31:15 | Re: AW: Re: GiST for 7.1 !! |