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
