Random 1/1000 second precison value and time zone offset added to Oracle DATE
type on GML and CSV output from WFS
-----------------------------------------------------------------------------------------------------------------
Key: GEOT-3525
URL: http://jira.codehaus.org/browse/GEOT-3525
Project: GeoTools
Issue Type: Bug
Affects Versions: 2.6.0
Environment: Geoserver 2.0.1, ARCSDE data store, Solaris 9, Tomcat 6,
Java 1.6.0_17
Reporter: Andrew Walsh
Using an ARCSDE data store with a simple point feature and a Oracle DATE type
column
a random 1/1000 second precision value is being added to the DATE. For example
a date
is stored as 2010-12-12 08:58:00 in the database but it is being output in GML
and CSV
as e.g 2010-12-12T08:58:00.567.
This, I feel, is incorrect as why should the time be altered?.
Instead '2010-12-12T08:58:00.00' should be output.
Here is an example of the GML output (note the random 0.751s value added to
the OBS_DATE_TIME)
<wfs:FeatureCollection numberOfFeatures="3"
timeStamp="2011-04-19T11:54:03.723+10:00"
xsi:schemaLocation="http://www.metoc.gov.au/test
http://www.metoc.gov.au/geoserver/wfs?service=WFS&version=1.1.0&;
request=DescribeFeatureType&typeName=test%3ATEST.BEACH_TEMPS
http://www.opengis.net/wfs
http://www.metoc.gov.au/geoserver/schemas/wfs/1.1.0/wfs.xsd";>
<gml:featureMembers>
<test:TEST.BEACH_TEMPS gml:id="TEST.BEACH_TEMPS.174">
<test:LON>151.3282</test:LON>
<test:LAT>-33.646</test:LAT>
<test:LOCATION>Bilgola</test:LOCATION>
<test:OBS_DATE_TIME>2010-11-18T09:09:00.751+11:00</test:OBS_DATE_TIME>
<test:TZONE>+11:00</test:TZONE>
<test:SST>19.3</test:SST>
<test:SHAPE>
<gml:Point srsName="urn:x-ogc:def:crs:EPSG:4326">
<gml:pos>-33.646000000000015 151.32820000000004</gml:pos>
</gml:Point>
</test:SHAPE>
</test:TEST.BEACH_TEMPS>
</gml:featureMembers>
</wfs:FeatureCollection>
and here is the CSV output (again note the random 0.048s value added):
TEST.BEACH_TEMPS.174, 151.3282, -33.646, Bilgola
2010-11-18T09:09:00.048,+11:00,19.3 ........
Another issue is the addition of a local timezone offset:
1) The GML output adds a local timezone offset i,e +10:00 (Sydney - EST) or
+11:00 (Sydney - Daylight Savings, Summer Time)
2) The CSV output gives NO timezone offset.
I would prefer if the output was the same the both GML and CSV
i.e NO timezone offset because we dealing a simple Oracle DATE type.
Only Oracle TIMESTAMP types are allowed to have a timezone.
To test the GML case enter this URL:
http://www.metoc.gov.au/geoserver/wfs?request=GetFeature&typeName=test:TEST.BEACH_TEMPS&cql_Filter=LOCATION%3D'Bilgola'&version=1.1.0
To test the CSV case enter this URL:
http://www.metoc.gov.au/geoserver/wfs?request=GetFeature&typeName=test:TEST.BEACH_TEMPS&cql_Filter=LOCATION%3D'Bilgola'&version=1.1.0&outputFormat=csv
Note also that this issue may be related to another problem in that an
OGC filter on a DATE range using >= and <= operators are not working.
This issue is raised in another ticket.
See the following email discussion thread about this ticket and related ones:
http://osgeo-org.1803224.n2.nabble.com/Date-comparisons-with-OGC-filter-and-CQL-filter-td6260247.html
--
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
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
