etic has been done in the time string. In all other cases it uses
the default timezone of the JVM.
From: andrea.a...@gmail.com [mailto:andrea.a...@gmail.com] On Behalf Of Andrea
Aime
Sent: Thursday, October 13, 2016 2:55 PM
To: Ian Turton
Cc: Walter Stovall ; geoserver-users
Subject: Re: [Geoserv
mezone) 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 00:00.
>>&g
cifically. Now what gets stored in my database is correct,
>> Jan 4 00:00.
>>
>>
>>
>> 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.
>>
>>
>>
>> Wha
e 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 [mailto:ijtur...@gmail.com]
> *Sent:* Thursday, October 13, 2016 9:54 AM
> *To:* Walter Stoval
ge?
Thanks for your help Ian!
Regards Walter Stovall
From: Ian Turton [mailto:ijtur...@gmail.com]
Sent: Thursday, October 13, 2016 9:54 AM
To: Walter Stovall
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] WFS will not read the same date that it stores
The GeoTools
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 onl
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 r
