Thanks, Ian, your workaround (disabling all but one time zone for PostgisDateOnlineTest) fixes the gt-jdbc-postgis build for me. I had a poke around and the JDBC driver changes the date in setDate on the prepared statement when the timezone is +14:00! Not sure why (and I have not yet attached source for that jar). I am willing to believe your conjecture that the original timezone is cached.
This commit of yours disabled the failing coverage: commit 79ea21088977bbc7900676495df3b7daa22101a3 Author: Ian Turton <[email protected]> Date: Thu Jun 4 14:00:02 2015 +0100 add workround for prepared statements (in Postgresql at least) caching the timezone. Kind regards, Ben. On 02/06/15 09:43, Ben Caradoc-Davies wrote: > I now see one new failure for the PS version of PostgisDateOnlineTest; > the non-PS version works fine. Tested in Maven with > {open,oracle}jdk{7,8} against postgresql 9.4.2-1 amd64 on debian/sid. > Also confirmed with openjdk7 in Eclipse. > > Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.256 > sec <<< FAILURE! - in org.geotools.data.postgis.ps.PostgisDateOnlineTest > testFiltersByDate(org.geotools.data.postgis.ps.PostgisDateOnlineTest) > Time elapsed: 0.112 sec <<< FAILURE! > junit.framework.AssertionFailedError: wrong number of records for > GMT+14:00 expected:<2> but was:<1> > at junit.framework.Assert.fail(Assert.java:57) > at junit.framework.Assert.failNotEquals(Assert.java:329) > at junit.framework.Assert.assertEquals(Assert.java:78) > at junit.framework.Assert.assertEquals(Assert.java:234) > at junit.framework.TestCase.assertEquals(TestCase.java:401) > at > org.geotools.jdbc.JDBCDateOnlineTest.testFiltersByDate(JDBCDateOnlineTest.java:63) -- Ben Caradoc-Davies <[email protected]> Director Transient Software Limited <http://transient.nz/> New Zealand ------------------------------------------------------------------------------ _______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
