AW: Re: tinterval - operator problems on AIX

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'lockhart(at)fourpalms(dot)org'" <lockhart(at)fourpalms(dot)org>
Cc: "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: AW: Re: tinterval - operator problems on AIX
Date: 2001-01-09 16:44:04
Message-ID: 11C1E6749A55D411A9670001FA6879633681A0@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> > 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2001-01-09 17:05:34 Re: AW: Re: tinterval - operator problems on AIX
Previous Message Bruce Momjian 2001-01-09 16:21:33 Re: README.mb