Re: AW: Re: tinterval - operator problems on AIX

Thomas Lockhart writes:
> > 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.

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.

The result of mktime for year < 1970 is always -1 and the struct tm is
not normalized; tm_isdst, tm_wday and tm_yday are not calculated. I
can't see that being a useful result.

> 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'm letting the system functions worry about applying time zone and
DST offsets. At no point do I use tm_isdst, except to set it to and
test it for -1.

Thinking about that a bit more, I think that tm_isdst should not be
written into. It would be better to set, say, tm_wday to -1 and
change the test for failure to (t_ago == -1 && local.tm_wday == -1).
tm_isdst should be left as 0 or 1 to help out around the times of
transition to or from DST.

> 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)).
--
Pete Forman -./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent
pete(dot)forman(at)westerngeco(dot)com -./\.- opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.