> > On AIX timestamp and horology regression fails in current, because
> > timestamp - interval for result timestamps that are before
> 1970 (epoch ?)
> > are off by one hour. I think this is not an issue for an
> adapted expected file,
> > but a new (in 7.1beta) bug. But I am at no means an expert
> at what the result
> > should be when substracting 34 years from epoch or 'Mon Dec
> 30 17:32:01 1996 PST'.
>
> Hi Andreas. It is certainly true that the behavior has changed for the
> new release, but afaik it can not be put into the "bug" category.
>
> The difference is that, before, I rotated date/time into the correct
> time zone for arithmetic by adding/subtracting the current time zone.
> For (date/time)-(interval), this resulted in evaluating the result in
> the same time zone as the starting date/time, which was not correct.
>
> The time zone is now evaluated in the time zone of the result, rather
> than the input, using system support routines from libc. But that will
> expose troubles on some platforms with time zone support before 1970.
> Some platforms are worse than others; my experience has been that
> zinc-based systems such as Linux, FreeBSD, and Tru64 are pretty good,
> Suns are the best, and, well, apparently AIX is not ;)
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.
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".
Andreas