Re: AW: AW: AW: Re: tinterval - operator problems on AIX
От | Thomas Lockhart |
---|---|
Тема | Re: AW: AW: AW: Re: tinterval - operator problems on AIX |
Дата | |
Msg-id | 3A5DCF0E.10D32844@alumni.caltech.edu обсуждение исходный текст |
Ответ на | AW: AW: AW: Re: tinterval - operator problems on AIX (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Список | pgsql-hackers |
> As I see it, the Linux results are also not 100 % correct in respect to dates > before 1970. (based on assumption that Solaris is correct) > < | Sat May 10 23:59:12 1947 PST > > | Sat May 10 23:59:12 1947 PDT > Was 1947 PDT or PST ? In eighter case one result is one hour off, Solaris or Linux. Yes, I've seen this before. As I mentioned, Solaris does a particularly good job of including the variations in DST definitions around WWII and earlier. In the US, there are several different conventions used in those years, presumably based on a need for energy conservation and perhaps to maximize production efficiency. > This raises another issue. Why do we distribute expected files with bogus results > in them? It depends on what you mean by "bogus". imho we should (and do) distribute "expected" files which reflect the results expected for a particular machine -- based on a careful analysis of the results from that machine from an expert, such as you are doing with AIX. Your results are incremental differences from some other "standard machine", which has also been carefully analyzed. By definition, the "standard machine" has been and is a Linux box, for the simple historical reason that this was my machine at the time that scrappy and I resurrected the regression tests several years ago. But it is a good choice for the standard, since that style of machine has a large installed base and the cost of entry for someone else wanting to participate is very low. If I understand the alternatives you are considering, the other choice is to distribute "expected" files which reflect what we think a machine should produce if it behaved the way we think it should. That doesn't really help anyone, since a tester would have to derive from first principles the correctness of the test results each time they run the test. Instead, we document the current behavior, and the regression tests can now catch *changes* in behavior, to be analyzed just as you are doing. If AIX fixes their mktime() and timezone behavior, you (or someone else running AIX) will see it, evaluate it, and adjust the regression "expected" files to reflect this. - Thomas
В списке pgsql-hackers по дате отправления: