It appears that when WFS executes a query, it correctly examines the localDateTimeHandling flag to avoid shifting the day back by one. But in the case of using WFS-T to insert a date, no such check is made and the day shifts when stored in the database. This results in the wrong day being reported in a subsequent query.
For example in my Oracle table I have an INSTALLED_DATE column of type DATE. My Oracle database has a dbtimezone of EST (-05:00:00 offset from GMT). I send a WFS insert transaction that populates the date as:
ov:INSPECTION_DATE2016-01-04</ov:INSPECTION_DATE>
If I then select the data in a sqlDev session, Oracle tells me the date is 03-Jan-16, where I would expect 04 instead of 03.
Then for grins I execute a WFS GetFeature with outputFormat=”JSON” and I see the date reported as “INSPECTION_DATE”:“2016-01-03”.
So, inserted 2016-01-04, query and get 2016-01-03.
I then changed the XsDateTimeFormat class as follows and apparently fixed this problem…I changed these lines:
if (parseTime) {
tz = TimeZone.getTimeZone(digits.toString());
} else {
// there’s no meaning for timezone if not parsing time
// http://en.wikipedia.org/wiki/ISO_8601
tz = TimeZone.getTimeZone(“GMT”);
}
My revised code reads as:
// Apply timezone arithmetic when z+/- has been used.
if (parseTime && digits.toString().length() != 3) {
// Set the timezone based on z+/- arithmetic in the time.
tz = TimeZone.getTimeZone(digits.toString());
} else {
// Set the timezone for times or dates based on the default.
// Note that timezone does have meaning for dates because
// it facilitates handling the value as a date/time of
// midnight that day and timezone changes can adjust the
// value of the date itself.
Object hint = Hints.getSystemDefault(Hints.LOCAL_DATE_TIME_HANDLING);
if(Boolean.TRUE.equals(hint)) {
// Use the time zone of the JVM
tz = TimeZone.getDefault();
} else {
tz = TimeZone.getTimeZone(“GMT”);
}
}
Thoughts on this as an acceptable mod?
Thanks – Walter Stovall
Byers Engineering Company
···
On Wed, Jun 22, 2016 at 9:50 AM, Chris Buckmaster <chris.buckmaster@…4589…> wrote:
The problem I am encountering is, for any dates that fall within British summer time (GMT Daylight Saving Time), it appears to be moving the actual date back by one day (i.e. for a date stored as 8th September 1993 in PostGIS, it is displaying as 07/09/1993 in my HTML / Javascript web application). The field is not a timestamp field, it is just a date field so from what I can gather it shouldn’t be storing any information on time zones?
There was a discussion about this topic on geotools-devel some time ago, the outcome was that yes, also dates have timezone (not hard to grasp,
e.g., now it’s Wednesday here in Europe, but in a few hours it will be Thursday in Australia). I believe that the outcome was also that it’s useful to add a configuration flag
for those that do not work in an international settings, so that the dates do not get modified in those cases.
According to the docs there is a system variable you can set:
http://docs.geotools.org/latest/userguide/library/metadata/geotools.html
So starting your JVM with -Dorg.geotools.localDateTimeHandling=true should change the behavior. It would be nice to have that as a global setting
in the GeoServer UI… anyone interested in coding it? 
Cheers
Andrea
–
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.