[Geoserver-users] WFS will not read the same date that it stores

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"?>

<Transaction

xmlns=“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”>

<INSTALLED_DATE>2016-01-04</INSTALLED_DATE>

Then I read it back with…

<?xml version="1.0" encoding="UTF-8"?>

<GetFeature

xmlns=“http://www.opengis.net/wfs

xmlns:fdot=“http://byers.com/nxwx/solution/fdot

xmlns:gml=“http://www.opengis.net/gml

xmlns:ogc=“http://www.opengis.net/ogc

version=“1.0.0”

service=“WFS”

outputFormat=“JSON”>

ogc:Filter

<ogc:FeatureId fid=“LAYER1.7649040”/>

</ogc:Filter>

In the JSON output I find…

“INSTALLED_DATE”:“2016-01-03Z”

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?

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 ™.

Ian

···

On 13 October 2016 at 14:33, Walter Stovall <walter.stovall@anonymised.com> 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"?>

<Transaction

xmlns=“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”>

<INSTALLED_DATE>2016-01-04</INSTALLED_DATE>

Then I read it back with…

<?xml version="1.0" encoding="UTF-8"?>

<GetFeature

xmlns=“http://www.opengis.net/wfs

xmlns:fdot=“http://byers.com/nxwx/solution/fdot

xmlns:gml=“http://www.opengis.net/gml

xmlns:ogc=“http://www.opengis.net/ogc

version=“1.0.0”

service=“WFS”

outputFormat=“JSON”>

ogc:Filter

<ogc:FeatureId fid=“LAYER1.7649040”/>

</ogc:Filter>

In the JSON output I find…

“INSTALLED_DATE”:“2016-01-03Z”

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, SlashDot.org! http://sdm.link/slashdot


Geoserver-users mailing list
Geoserver-users@anonymised.com.382…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Ian Turton

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

// http://en.wikipedia.org/wiki/ISO_8601

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 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.

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

···

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 ™.

Ian

On 13 October 2016 at 14:33, Walter Stovall <walter.stovall@…7262…> 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"?>

<Transaction

xmlns=“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”>

<INSTALLED_DATE>2016-01-04</INSTALLED_DATE>

Then I read it back with…

<?xml version="1.0" encoding="UTF-8"?>

<GetFeature

xmlns=“http://www.opengis.net/wfs

xmlns:fdot=“http://byers.com/nxwx/solution/fdot

xmlns:gml=“http://www.opengis.net/gml

xmlns:ogc=“http://www.opengis.net/ogc

version=“1.0.0”

service=“WFS”

outputFormat=“JSON”>

ogc:Filter

<ogc:FeatureId fid=“LAYER1.7649040”/>

</ogc:Filter>

In the JSON output I find…

“INSTALLED_DATE”:“2016-01-03Z”

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, SlashDot.org! http://sdm.link/slashdot


Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Ian Turton

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” <walter.stovall@anonymised.com> wrote:

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

// http://en.wikipedia.org/wiki/ISO_8601

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 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.

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 [mailto:ijturton@anonymised.com]
Sent: Thursday, October 13, 2016 9:54 AM
To: Walter Stovall <walter.stovall@anonymised.com>
Cc: geoserver-users@anonymised.comsourceforge.net
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 ™.

Ian

On 13 October 2016 at 14:33, Walter Stovall <walter.stovall@anonymised.com…7262…> 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"?>

<Transaction

xmlns=“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”>

<INSTALLED_DATE>2016-01-04</INSTALLED_DATE>

Then I read it back with…

<?xml version="1.0" encoding="UTF-8"?>

<GetFeature

xmlns=“http://www.opengis.net/wfs

xmlns:fdot=“http://byers.com/nxwx/solution/fdot

xmlns:gml=“http://www.opengis.net/gml

xmlns:ogc=“http://www.opengis.net/ogc

version=“1.0.0”

service=“WFS”

outputFormat=“JSON”>

ogc:Filter

<ogc:FeatureId fid=“LAYER1.7649040”/>

</ogc:Filter>

In the JSON output I find…

“INSTALLED_DATE”:“2016-01-03Z”

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, SlashDot.org! http://sdm.link/slashdot


Geoserver-users mailing list
Geoserver-users@anonymised.comsourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Ian Turton

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 <ijturton@anonymised.com> wrote:

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


Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


Geoserver-users mailing list
Geoserver-users@anonymised.com.382…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

On 13 Oct 2016 16:28, “Walter Stovall” <walter.stovall@anonymised.com> wrote:

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

// http://en.wikipedia.org/wiki/ISO_8601

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 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.

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 [mailto:ijturton@anonymised.com]
Sent: Thursday, October 13, 2016 9:54 AM
To: Walter Stovall <walter.stovall@anonymised.com>
Cc: geoserver-users@anonymised.comrge.net
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 ™.

Ian

On 13 October 2016 at 14:33, Walter Stovall <walter.stovall@anonymised.com…7262…> 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"?>

<Transaction

xmlns=“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”>

<INSTALLED_DATE>2016-01-04</INSTALLED_DATE>

Then I read it back with…

<?xml version="1.0" encoding="UTF-8"?>

<GetFeature

xmlns=“http://www.opengis.net/wfs

xmlns:fdot=“http://byers.com/nxwx/solution/fdot

xmlns:gml=“http://www.opengis.net/gml

xmlns:ogc=“http://www.opengis.net/ogc

version=“1.0.0”

service=“WFS”

outputFormat=“JSON”>

ogc:Filter

<ogc:FeatureId fid=“LAYER1.7649040”/>

</ogc:Filter>

In the JSON output I find…

“INSTALLED_DATE”:“2016-01-03Z”

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, SlashDot.org! http://sdm.link/slashdot


Geoserver-users mailing list
Geoserver-users@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Ian Turton

==
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://www.geo-solutions.it
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.


I am pretty sure that was me. But I’ll check tomorrow.

Ian

···

On 13 Oct 2016 19:54, “Andrea Aime” <andrea.aime@anonymised.com> 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 that?

Cheers
Andrea

On Thu, Oct 13, 2016 at 8:22 PM, Ian Turton <ijturton@anonymised.com> wrote:

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


Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


Geoserver-users mailing list
Geoserver-users@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

==
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://www.geo-solutions.it
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.


On 13 Oct 2016 16:28, “Walter Stovall” <walter.stovall@anonymised.com> wrote:

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

// http://en.wikipedia.org/wiki/ISO_8601

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 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.

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 [mailto:ijturton@anonymised.com]
Sent: Thursday, October 13, 2016 9:54 AM
To: Walter Stovall <walter.stovall@anonymised.com>
Cc: geoserver-users@anonymised.comrge.net
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 ™.

Ian

On 13 October 2016 at 14:33, Walter Stovall <walter.stovall@anonymised.com…7262…> 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"?>

<Transaction

xmlns=“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”>

<INSTALLED_DATE>2016-01-04</INSTALLED_DATE>

Then I read it back with…

<?xml version="1.0" encoding="UTF-8"?>

<GetFeature

xmlns=“http://www.opengis.net/wfs

xmlns:fdot=“http://byers.com/nxwx/solution/fdot

xmlns:gml=“http://www.opengis.net/gml

xmlns:ogc=“http://www.opengis.net/ogc

version=“1.0.0”

service=“WFS”

outputFormat=“JSON”>

ogc:Filter

<ogc:FeatureId fid=“LAYER1.7649040”/>

</ogc:Filter>

In the JSON output I find…

“INSTALLED_DATE”:“2016-01-03Z”

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, SlashDot.org! http://sdm.link/slashdot


Geoserver-users mailing list
Geoserver-users@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Ian Turton

There’s also a problem handling date/times. See the following Insert transaction that populates an Oracle column of type TIMESTAMP.

<?xml version="1.0" encoding="UTF-8"?>

<Transaction
xmlns=“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”>

2016-01-04T00:00:00</ TSTEST>

This attempts to store a date/time of 1/4/2016 00:00:00. What actually gets stored in Oracle is 1/3/2016 07:00:00 PM.

I have fixed both the date and date/time problems in my development environment as follows:

See the code below in XsDateTimeFormat, unchanged from the github download of GeoTools:

TimeZone tz;

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”);

}

Here are my changes to that block of code:

TimeZone tz;

// 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.

tz = TimeZone.getDefault();

}

The differences in my code is that it uses the GMT+/- offset timezone only if z+/- arithmetic has been done in the time string. In all other cases it uses the default timezone of the JVM.

···

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 <ijturton@…84…> wrote:

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” <walter.stovall@…7262…> wrote:

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

// http://en.wikipedia.org/wiki/ISO_8601

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 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.

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 [mailto:ijturton@…84…]
Sent: Thursday, October 13, 2016 9:54 AM
To: Walter Stovall <walter.stovall@…7262…>
Cc: geoserver-users@lists.sourceforge.net
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 ™.

Ian

On 13 October 2016 at 14:33, Walter Stovall <walter.stovall@…7262…> 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"?>

<Transaction

xmlns=“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”>

<INSTALLED_DATE>2016-01-04</INSTALLED_DATE>

Then I read it back with…

<?xml version="1.0" encoding="UTF-8"?>

<GetFeature

xmlns=“http://www.opengis.net/wfs

xmlns:fdot=“http://byers.com/nxwx/solution/fdot

xmlns:gml=“http://www.opengis.net/gml

xmlns:ogc=“http://www.opengis.net/ogc

version=“1.0.0”

service=“WFS”

outputFormat=“JSON”>

ogc:Filter

<ogc:FeatureId fid=“LAYER1.7649040”/>

</ogc:Filter>

In the JSON output I find…

“INSTALLED_DATE”:“2016-01-03Z”

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, SlashDot.org! http://sdm.link/slashdot


Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Ian Turton


Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

==

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://www.geo-solutions.it

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.


I tried entering a bug as suggested by Ian below but I’m having trouble with my account at https://osgeo-org.atlassian.net. I’m not getting the password right. If a try to signup it tells me my userid already exists. But if I follow the having-trouble link and say I forgot my password then I get “we didn’t recognize the user/password”.

ATT00001.txt (205 Bytes)

ATT00002.txt (180 Bytes)

···

From: Walter Stovall
Sent: Friday, October 14, 2016 6:27 AM
To: Andrea Aime <andrea.aime@…1107…>; Ian Turton <ijturton@…84…>
Cc: geoserver-users geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] WFS will not read the same date that it stores

There’s also a problem handling date/times. See the following Insert transaction that populates an Oracle column of type TIMESTAMP.

<?xml version="1.0" encoding="UTF-8"?>

<Transaction
xmlns=“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”>

2016-01-04T00:00:00</ TSTEST>

This attempts to store a date/time of 1/4/2016 00:00:00. What actually gets stored in Oracle is 1/3/2016 07:00:00 PM.

I have fixed both the date and date/time problems in my development environment as follows:

See the code below in XsDateTimeFormat, unchanged from the github download of GeoTools:

TimeZone tz;

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”);

}

Here are my changes to that block of code:

TimeZone tz;

// 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.

tz = TimeZone.getDefault();

}

The differences in my code is that it uses the GMT+/- offset timezone only if z+/- arithmetic has been done in the time string. In all other cases it uses the default timezone of the JVM.

From: andrea.aime@…84… [mailto:andrea.aime@…84…] On Behalf Of Andrea Aime
Sent: Thursday, October 13, 2016 2:55 PM
To: Ian Turton <ijturton@…84…>
Cc: Walter Stovall <walter.stovall@…7262…>; geoserver-users <geoserver-users@lists.sourceforge.net>
Subject: Re: [Geoserver-users] WFS will not read the same date that it stores

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 <ijturton@…84…> wrote:

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” <walter.stovall@…7262…> wrote:

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

// http://en.wikipedia.org/wiki/ISO_8601

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 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.

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 [mailto:ijturton@…84…]
Sent: Thursday, October 13, 2016 9:54 AM
To: Walter Stovall <walter.stovall@…7262…>
Cc: geoserver-users@lists.sourceforge.net
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 ™.

Ian

On 13 October 2016 at 14:33, Walter Stovall <walter.stovall@…7262…> 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"?>

<Transaction

xmlns=“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”>

<INSTALLED_DATE>2016-01-04</INSTALLED_DATE>

Then I read it back with…

<?xml version="1.0" encoding="UTF-8"?>

<GetFeature

xmlns=“http://www.opengis.net/wfs

xmlns:fdot=“http://byers.com/nxwx/solution/fdot

xmlns:gml=“http://www.opengis.net/gml

xmlns:ogc=“http://www.opengis.net/ogc

version=“1.0.0”

service=“WFS”

outputFormat=“JSON”>

ogc:Filter

<ogc:FeatureId fid=“LAYER1.7649040”/>

</ogc:Filter>

In the JSON output I find…

“INSTALLED_DATE”:“2016-01-03Z”

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, SlashDot.org! http://sdm.link/slashdot


Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Ian Turton


Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

==

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://www.geo-solutions.it

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.


Hello to you all,
seems that a long time has passed since the last question was asked but I am having this very same issue.
Although using a old release, If anyone can point to some documentation or fix it would be veeery nice.
Thank you all for this incredible work.

The settings they are talking about is from the GeoTools project:

-Duser.timezone=America/Vancouver
-Dorg.geotools.localDateTimeHandling=true

I added a section to the user manual about managing application properties but I am not sure if this specific one is listed.

1 Like

Thanks for pointing out to the link Jive.
This is a particular case in which I do not have access to the JVM Settings easily unfortunately.
Is there any way to send a date with a sign to the desired timezone? Like a ‘2024-09-23Z’ to denote it is already in UTC?

Perhaps; I wonder what CQL accepts for time?

Looking at the grammar I do not see timezone - oh wait it is there:

  <date-time> ::= <full-date> T <UTC-time

I always look for test cases to learn what code actually does:

  1. Finding the module, looking in src/test/java/
  2. Something called ECQLTemporalPredicateTest.java is probably appropriate
  3. Here is an example: 2006-11-30T01:00:00Z BEFORE 2006-11-30T01:30:00Z

Questions:

  • Q: Does this work for you? If so please reply
  • Q: Did you look in the user manual? If so use edit to provide an example there also…

The information about giving a Z at the end comes from the mailing list where Justin Deoliveira pointed to this direction:
https://sourceforge.net/p/geoserver/mailman/message/12504376/

Try specifying a “Z” at the end of your date time. For instance:
2006-12-14T12:08:13Z

So after testing carefully, I see that putting a Z indeed works as expected, but also I realize that my problem about “WFS dates being changed” was more Qgis (unaware user) related, as it is converting the UTM values to my locale for WFS layer and not for geojson so with a simple feature attribute identify inspection it seems to be storing a different datetime, with a day difference when close to midnight.
Sorry to bother you all and thanks for the help.