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

> What I do not understand is, that I thought a time in december cannot be
> affected by such math because it is clearly not in the daylight savings
> months of the year ? Also I thought that you recognize daylight savings time
> by the PDT instead of PST, and PostgreSQL shows a result with PST as I
> would have expected, but one hour off.

By the time the math is actually done, the date is in GMT. So the issue
is: how does one assign the time zone for the result? Or more properly,
how does one account for time zone shifts (e.g. Daylight time vs
Standard time) when doing date/time arithmetic? The previous scheme
rotated the date/time by the same amount as the original date input. The
current scheme uses your system's date/time support functions to deduce
the correct time zone and DST setting once the math is complete. In
principle, this gives your system the opportunity to come up with the
correct answer, where previously the answer was not what might be
expected for any platform.

> e.g.: Mon Dec 30 17:32:01 1996 PST - @ 34 years --> Sun Dec 30 16:32:01 1962 PST
> How do we go about resolving this ? I hesitate to mark a bogus result
> "ok".

The result must be what the AIX developers want ;)

I've made some assumptions in this conversation:

1) Some platforms, Linux included, give "correct results". I think I
checked this thoroughly, but, well, you know how that goes sometimes...

2) You are diff'ing the current "expected" against current "results",
and not a previous version of "expected".

3) Some platforms do not do the right thing wrt time zones for dates
before 1970. For example, the USA had some weird time zones during WWII,
and this is reflected in Sun's time zone database but not quite as
accurately in the open source zinc package that Linux and others use.
And other platforms (such as AIX?) prefer to do it themselves and get it
wrong altogether.

- Thomas