Thanks for the advice. Unfortunately following that path does not work for me.  
I still end up with dates that are one-behind.

This was discovered with a more complicated arrangement, but I have this 
problem in my simple test environment where my geoserver is deployed to a local 
tomcat 8 on my Windows workstation.  This is a computer setup for Eastern 
Standard Daylight time (which is an offset of -05:00).

I browse to my http://localhost:8080/geoserver/web webapp and run the Demo page 
where I paste in the WFS-T Insert request I showed earlier that inserts a date 
of 01/04/2016.  Then I see a new row has showed up in my back-end Oracle table 
where geoserver is storing these features with the OracleNGDataStore.  
Selecting the date from that row, I get 01/03/2016.  If I drill down by asking 
Oracle to show the time too I’ll get 03-jan-2016 19:00:00.  So obviously 
“somebody” is applying the -05:00 offset by the time the data is given to the 
Oracle driver. fwiw the Oracle dbtimezone is -04:00 but that hardly matters 
because Oracle expects to be given the data in the “correct” timezone and just 
stores what you give it.

I’ve already discovered by watching the geoserver log that Oracle is receiving 
the wrong value.

To find out more I build an eclipse workspace that includes geoserver and 
geotools and attach to the running tomcat.
So first I break in the debugger at SimpleFeatureImpl which is getting hit by 
the SAX parsing invoked by WfsXmlReader.  The values object array there has a 
date of “2016-01-03” (which is the toString output of Gregorian$Date with a 
fastTime of 1451865600000). This is ultimately going to become Jan 3 19:00 
stored in Oracle.  So I know things are bad already.

Backtracking to see where things went wrong I back all the way up to where the 
Jan 4 date is getting parsed out of the XML for my WFS-T insert request.  I 
stop at XsDateTimeFormat.parseObject(String, ParsePosition, boolean) and in 
there I see where there’s an assumption that the timezone will ALWAYS be GMT…

        if (parseTime) {
            tz = TimeZone.getTimeZone(digits.toString());
        } else {
            // there's no meaning for timezone if not parsing time
            tz = TimeZone.getTimeZone("GMT");
        Calendar cal = Calendar.getInstance(tz);

So regardless of environment variables etc. I know that at this stage my 
incoming date is always represented as Jan 4 2016 GMT.  It would appear that 
later this gets represented as EDT (my timezone) and becomes Jan 3 19:00.

So I patched my code just now to call TimeZone.getDefault() instead of using 
“GMT” specifically.  Now what gets stored in my database is correct, Jan 4 

As to whether this specifically is a fix and whether similar problems wait for 
me with datetime vs. just date, I’m unclear at this point.

What are your thoughts about this?  Do I have a way to make it work without a 
code change?

Thanks for your help Ian!

Regards Walter Stovall

From: Ian Turton []
Sent: Thursday, October 13, 2016 9:54 AM
To: Walter Stovall <>
Subject: Re: [Geoserver-users] WFS will not read the same date that it stores

The GeoTools/GeoServer data handler should use the timezone of the server (so 
if that is set to GMT then you need to convert before sending). This allows for 
servers where clients can be in multiple timezones and need to agree a fixed 
timezone when communicating with the server.

If you are the only user of the client/server then you should be able to set 
the timezone on the server and client to the same one and it should all just 
work (tm).


On 13 October 2016 at 14:33, Walter Stovall 
<<>> wrote:
Using GeoServer2.8 I’m having a very basic problem with WFS-T inserting a 
feature that has date fields.  When I do a GetFeature to retrieve the date I 
inserted, I get a value that’s one-day prior to the date I inserted.  This 
appears to be related to the GeoTools xsDateTimeFormat class used to read the 
incoming XML on my insert-request and the code’s assumption that the incoming 
date is in the GMT timezone.  Do clients of WFS have to convert all their dates 
to GMT before inserting them??

Here is an example transaction that I use for insert…
<?xml version="1.0" encoding="UTF-8"?>
    <LAYER1 fid="none">

Then I read it back with…
<?xml version="1.0" encoding="UTF-8"?>
  <Query typeName="LAYER1">
      <ogc:FeatureId fid="LAYER1.7649040"/>

In the JSON output I find…

So I stored 1/4/2016, I read back 1/3/2016.

My back-end datastore is Oracle. When I select directly from the database I 
find the wrong value there too.
SELECT TO_CHAR(installed_date, 'dd-mon-yyyy hh24:mi:ss')…

This gives me… 03-jan-2016 19:00:00.

How do I set things up so a WFS client that stores 1/4/2016 gets 1/4/2016 back?

Check out the vibrant tech community on one of the world's most
engaging tech sites,!
Geoserver-users mailing list<>

Ian Turton
Check out the vibrant tech community on one of the world's most 
engaging tech sites,!
Geoserver-users mailing list

Reply via email to