There’s also a problem handling date/times. See the following Insert
transaction that populates an Oracle column of type TIMESTAMP.
http://www.opengis.net/wfs;
xmlns:gml="http://www.opengis.net/gml;
xmlns:ogc="http://www.opengis.net/ogc;
version="1.0.0"
service="WFS">
I am pretty sure that was me. But I'll check tomorrow.
Ian
On 13 Oct 2016 19:54, "Andrea Aime" wrote:
> Ian, going by memory and answering from my tablet... didn't someone
> contribute a patch to make
> dates timezone independent? With a system variable to set
Ian, going by memory and answering from my tablet... didn't someone
contribute a patch to make
dates timezone independent? With a system variable to set that?
Cheers
Andrea
On Thu, Oct 13, 2016 at 8:22 PM, Ian Turton wrote:
> That sounds like a regression to me, when I'm
That sounds like a regression to me, when I'm back at my desk, I'll dig out
the previous tests and check how that slipped in.
Can you raise a bug in the meantime so I don't forget.
Ian
On 13 Oct 2016 16:28, "Walter Stovall" wrote:
> Thanks for the advice.
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
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
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