Build failure in gt-shapefile ShapefileDataStoreTest caused by daylight saving data corruption ----------------------------------------------------------------------------------------------
Key: GEOT-2925 URL: http://jira.codehaus.org/browse/GEOT-2925 Project: GeoTools Issue Type: Bug Components: data shapefile Environment: Perth, Western Australia (yes this is important) Reporter: Ben Caradoc-Davies Assignee: Andrea Aime Priority: Blocker The build is broken in some locales by a gt-shapefile ShapefileDataStoreTest failure caused by incorrect timezone handling in DbaseFileReader. {code} Failed tests: testReadWriteDate(org.geotools.data.shapefile.ShapefileDataStoreTest) {code} This unit test was added by simonegiannecchini in r34805. Credit to Simone, who has uncovered a longstanding timezone handling bug, which causes data corruption. The failure: {code} junit.framework.AssertionFailedError: expected:<Fri Dec 12 06:10:20 WST 2008> but was:<Fri Dec 12 07:10:20 WST 2008> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:277) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:71) at org.geotools.data.shapefile.ShapefileDataStoreTest.testReadWriteDate(ShapefileDataStoreTest.java:345) ... {code} I think the problem lies in the "case '@'" block at line 484 in DbaseFileReader, in which it is assumed that a timestamp can be reconstituted by calculating the number of milliseconds since the Gregorian epoch using the the day number, and then adding the number of milliseconds since the start of the day. This can only work if the local time zone UTC offset is the same as for 1 January 4713 BC. This is likely true for northern locales that typically do not observe daylight saving during winter. It is likely false for southern locales that observe daylight saving in summer. In the southern hemisphere, many jurisdictions observe daylight saving during the summer months, typically including December. Western Australia trialled daylight saving starting in 2006, 2007, and 2008. It was rejected in a referendum in 2009. This unit test fails in Western Australia for dates in December 2006, 2007, and 2008, but not for several other December dates this millennium. I am surprised to see the local timezone used in this code. In my experience, timestamps are useless without an explicit timezone. Does the shapefile format mandate a timezone (in which case we should use it), or just assume the local timezone (problematic)? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel