AW: Re: tinterval - operator problems on AIX
От | Zeugswetter Andreas SB |
---|---|
Тема | AW: Re: tinterval - operator problems on AIX |
Дата | |
Msg-id | 11C1E6749A55D411A9670001FA6879633681A0@sdexcsrv1.f000.d0188.sd.spardat.at обсуждение исходный текст |
Список | 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
В списке pgsql-hackers по дате отправления: