| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | lockhart(at)fourpalms(dot)org |
| Cc: | bpalmer <bpalmer(at)crimelabs(dot)net>, "Dominic J(dot) Eidson" <sauron(at)the-infinite(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Final call for platform testing |
| Date: | 2001-04-03 18:17:05 |
| Message-ID: | 6357.986321825@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> Not sure how to test the "implicit time zone" feature of "TIME WITH TIME
> ZONE" without risking the same kinds of trouble. Maybe the test should
> be recast to using only comparisons with other date/time types which
> have been shown to behave themselves across time zone boundaries. But
> I'm not sure that this would continue to really test the feature.
I suspect we have no choice but to eliminate this particular test from
the regression suite. A test that fails for a few days around DST
boundaries is one thing, but a test that fails for six months out of the
year is another.
BTW, the reason HPUX was failing to fail is that its mktime() is picky
about tm_year; we were forgetting to subtract off 1900 in that
particular code path. Fixed. Now I get a failure like everyone else ;-)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-04-03 18:33:33 | pg_dump performance lossage for primary keys |
| Previous Message | Jeff Duffy | 2001-04-03 17:40:41 | Re: Final call for platform testing |