GEOT-5329: Proposal to avoid Date-shifting due to Timezones

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

GEOT-5329: Proposal to avoid Date-shifting due to Timezones

Andreas Watermeyer
Hi GeoTools-Developers,

I recently created https://osgeo-org.atlassian.net/browse/GEOT-5329 to
propose a patch to change GeoTools java.sql.Date to String conversion
due to problems arising from timezones.

Andrea Aime suggested involve this mailing list.

Problem:
A date (without time) in Postgres (2015-12-18) is delivered to client
as 2015-12-17Z.
This occurs due to internal time zone conversion to GMT.

My understanding (from https://en.wikipedia.org/wiki/ISO_8601):
Dates (without time component) are not related to time zones. They are
unaware of time zones.

Additionally:
When talking about dates (without time), it does not matter, at which
*time* the day starts or ends, it is just a date (without time). That
means: People in Europe and Australia have same understanding of Jan
1st, but they have if different understand about when the day starts
or ends. But this is about times *not* about dates.

So, my suggestion is as follows:
A date (without time) should not be changed on transfer, no matter of
time zone boundaries.

Reason:
Dates are not time zone dependent. If somebody wants time zone
dependent behaviour, it is required to specify a date and time, not a
pure date.

In Java Objects:
Date (without time): java.sql.Date - shall be transferred unaware of time zones
Date (with time):  java.util.Date - shall be transferred using time
zone shifting
The proposed patch implements this concept.

In other words:
I think it is very unlikely, that anybody expects a date (without
time) to be shifted, because of time zone difference. Especially in
cases of a small offset of +/- 1h.
The current behaviour implies that GeoTools consumers treat dates
(without time) as timezone-aware date and time objects, transfer the
date and time into the local time zone and treat it as date again.

Note:
Unfortunately java.sql.Date is internally time-based, which is an
often criticized design decision and leads to constant confusion. I
think this is the actual reason for this issue.

One further aspect:
GeoTools currently formats dates as "2015-12-18Z", "Z" for time zone
UTC ("Zulu").
As far as I know this is required to be CITE compliant. Due to
https://en.wikipedia.org/wiki/ISO_8601 this is not a valid format for
dates (without time). But maybe wikipedia is incomplete.
I am not suggesting to change this behaviour, although it make no
sense, in my opinion.

Technical Conclusion:
The patch is based on the assumption, that java.sql.Date objects
should be treated as date  without time. Dates without time should not
be changed on transfer across time zone boundaries. Therefore
java.sql.Date shall be converted to a string reflecting the local
meaning. In the current implementation this means, that the time zone
offset has to be considered to neutralized time zone effects.

This is my point of view. I hoper the majority can follow my suggestion.

With best regards,

Andreas
----------------------------------------------------------------
ITS Telco Services GmbH
GIS Services & Solutions
Telecommunications Division
Dillenburger Str. 77
D-51105 Köln
Tel.: +49 (0)221 820 07 00
Fax : +49 (0)221 820 07 22
Mail: [hidden email]
Web : http://www.its-telco.de
----------------------------------------------------------------
Sitz der Gesellschaft: Köln
Amtsgericht Köln, HRB 59310
Geschäftsführer: Gunnar Haack, Ralf Petersilka, Michael Schnepf, Kai
Schriewer, Ludger Schulte
----------------------------------------------------------------

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der
richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese
E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the
intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in
this e-mail is strictly forbidden.

------------------------------------------------------------------------------
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

jody.garnett
Hey Andreas, interesting discussion.

I just rejected a "workaround" (https://github.com/geotools/geotools/pull/997) on a similar topic - dealing with dates far in the past.

We tend to base our datastore / query / filter API off the WFS - in particular we may be able to check the OGC docs for clarification (or ask on the [hidden email] email list).

While your argument makes sense to me I would like to focus on interoperability if we can.


--
Jody Garnett

On 18 December 2015 at 03:44, Andreas Watermeyer <[hidden email]> wrote:
Hi GeoTools-Developers,

I recently created https://osgeo-org.atlassian.net/browse/GEOT-5329 to
propose a patch to change GeoTools java.sql.Date to String conversion
due to problems arising from timezones.

Andrea Aime suggested involve this mailing list.

Problem:
A date (without time) in Postgres (2015-12-18) is delivered to client
as 2015-12-17Z.
This occurs due to internal time zone conversion to GMT.

My understanding (from https://en.wikipedia.org/wiki/ISO_8601):
Dates (without time component) are not related to time zones. They are
unaware of time zones.

Additionally:
When talking about dates (without time), it does not matter, at which
*time* the day starts or ends, it is just a date (without time). That
means: People in Europe and Australia have same understanding of Jan
1st, but they have if different understand about when the day starts
or ends. But this is about times *not* about dates.

So, my suggestion is as follows:
A date (without time) should not be changed on transfer, no matter of
time zone boundaries.

Reason:
Dates are not time zone dependent. If somebody wants time zone
dependent behaviour, it is required to specify a date and time, not a
pure date.

In Java Objects:
Date (without time): java.sql.Date - shall be transferred unaware of time zones
Date (with time):  java.util.Date - shall be transferred using time
zone shifting
The proposed patch implements this concept.

In other words:
I think it is very unlikely, that anybody expects a date (without
time) to be shifted, because of time zone difference. Especially in
cases of a small offset of +/- 1h.
The current behaviour implies that GeoTools consumers treat dates
(without time) as timezone-aware date and time objects, transfer the
date and time into the local time zone and treat it as date again.

Note:
Unfortunately java.sql.Date is internally time-based, which is an
often criticized design decision and leads to constant confusion. I
think this is the actual reason for this issue.

One further aspect:
GeoTools currently formats dates as "2015-12-18Z", "Z" for time zone
UTC ("Zulu").
As far as I know this is required to be CITE compliant. Due to
https://en.wikipedia.org/wiki/ISO_8601 this is not a valid format for
dates (without time). But maybe wikipedia is incomplete.
I am not suggesting to change this behaviour, although it make no
sense, in my opinion.

Technical Conclusion:
The patch is based on the assumption, that java.sql.Date objects
should be treated as date  without time. Dates without time should not
be changed on transfer across time zone boundaries. Therefore
java.sql.Date shall be converted to a string reflecting the local
meaning. In the current implementation this means, that the time zone
offset has to be considered to neutralized time zone effects.

This is my point of view. I hoper the majority can follow my suggestion.

With best regards,

Andreas
----------------------------------------------------------------
ITS Telco Services GmbH
GIS Services & Solutions
Telecommunications Division
Dillenburger Str. 77
D-51105 Köln
Tel.: <a href="tel:%2B49%20%280%29221%20820%2007%2000" value="+492218200700">+49 (0)221 820 07 00
Fax : <a href="tel:%2B49%20%280%29221%20820%2007%2022" value="+492218200722">+49 (0)221 820 07 22
Mail: [hidden email]
Web : http://www.its-telco.de
----------------------------------------------------------------
Sitz der Gesellschaft: Köln
Amtsgericht Köln, HRB 59310
Geschäftsführer: Gunnar Haack, Ralf Petersilka, Michael Schnepf, Kai
Schriewer, Ludger Schulte
----------------------------------------------------------------

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der
richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese
E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the
intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in
this e-mail is strictly forbidden.

------------------------------------------------------------------------------
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel


------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

geowolf
Hi Jody,
there is indeed a chance this change will break CITE testing, however, we
are running a old and buggy version of it.
After six months of waiting for the new engine to be deployed on ares I've
honestly lost interest and gave up (others feel free to resume the effort), 
but if we ever do get stuff on there, this change should probably be revisited.

In particular, formatting the date with a Z ending it just seems out of spec,
dates do not seem to have a timezone specifier:

Unless of course the wikipedia page misses some information compared
to the actual full ISO8601 standard.

Now, to be honest, the notion of a date without a timezone is rather counter-intuitive 
to me (probably because I'm too used to work across a large span of timezones). 
Right now If you ask me what day it is, I'll say Saturday, but if we ask Jody, he'll say Friday (it's 8am
now in italy, but 11pm of the day before in Victoria, Canada). 
That is, to me, it does not make sense to talk about a date without a notion
of timezone... it would not even make sense to have a thing called the
international date line, a line that when crossed changes the current

Citing a fitting example from that page:
"Christmas, for example, is celebrated on 25 December (according to either the Gregorian or the Julian calendar, depending upon which of the two is used by the particular church) as that date falls in countries located on either side of the Date Line. Thus, whether it is Western Christmas or Orthodox Christmas, Christians in Samoa, immediately west of the Date Line, will celebrate the holiday a day before Christians in American Samoa, which is immediately east of the Date Line"

That said, I fully understand that storing a pure date in a database, and
have it changed by the GML output to the day before/after is
quite maddening, unless someone is really working in an international,
world wide, setting (at which point, they probably want to be more precise
and use full timestamps)

Maybe we should have some sort of way to control this behavior?

Cheers
Andrea


On Sat, Dec 19, 2015 at 1:52 AM, Jody Garnett <[hidden email]> wrote:
Hey Andreas, interesting discussion.

I just rejected a "workaround" (https://github.com/geotools/geotools/pull/997) on a similar topic - dealing with dates far in the past.

We tend to base our datastore / query / filter API off the WFS - in particular we may be able to check the OGC docs for clarification (or ask on the [hidden email] email list).

While your argument makes sense to me I would like to focus on interoperability if we can.


--
Jody Garnett

On 18 December 2015 at 03:44, Andreas Watermeyer <[hidden email]> wrote:
Hi GeoTools-Developers,

I recently created https://osgeo-org.atlassian.net/browse/GEOT-5329 to
propose a patch to change GeoTools java.sql.Date to String conversion
due to problems arising from timezones.

Andrea Aime suggested involve this mailing list.

Problem:
A date (without time) in Postgres (2015-12-18) is delivered to client
as 2015-12-17Z.
This occurs due to internal time zone conversion to GMT.

My understanding (from https://en.wikipedia.org/wiki/ISO_8601):
Dates (without time component) are not related to time zones. They are
unaware of time zones.

Additionally:
When talking about dates (without time), it does not matter, at which
*time* the day starts or ends, it is just a date (without time). That
means: People in Europe and Australia have same understanding of Jan
1st, but they have if different understand about when the day starts
or ends. But this is about times *not* about dates.

So, my suggestion is as follows:
A date (without time) should not be changed on transfer, no matter of
time zone boundaries.

Reason:
Dates are not time zone dependent. If somebody wants time zone
dependent behaviour, it is required to specify a date and time, not a
pure date.

In Java Objects:
Date (without time): java.sql.Date - shall be transferred unaware of time zones
Date (with time):  java.util.Date - shall be transferred using time
zone shifting
The proposed patch implements this concept.

In other words:
I think it is very unlikely, that anybody expects a date (without
time) to be shifted, because of time zone difference. Especially in
cases of a small offset of +/- 1h.
The current behaviour implies that GeoTools consumers treat dates
(without time) as timezone-aware date and time objects, transfer the
date and time into the local time zone and treat it as date again.

Note:
Unfortunately java.sql.Date is internally time-based, which is an
often criticized design decision and leads to constant confusion. I
think this is the actual reason for this issue.

One further aspect:
GeoTools currently formats dates as "2015-12-18Z", "Z" for time zone
UTC ("Zulu").
As far as I know this is required to be CITE compliant. Due to
https://en.wikipedia.org/wiki/ISO_8601 this is not a valid format for
dates (without time). But maybe wikipedia is incomplete.
I am not suggesting to change this behaviour, although it make no
sense, in my opinion.

Technical Conclusion:
The patch is based on the assumption, that java.sql.Date objects
should be treated as date  without time. Dates without time should not
be changed on transfer across time zone boundaries. Therefore
java.sql.Date shall be converted to a string reflecting the local
meaning. In the current implementation this means, that the time zone
offset has to be considered to neutralized time zone effects.

This is my point of view. I hoper the majority can follow my suggestion.

With best regards,

Andreas
----------------------------------------------------------------
ITS Telco Services GmbH
GIS Services & Solutions
Telecommunications Division
Dillenburger Str. 77
D-51105 Köln
Tel.: <a href="tel:%2B49%20%280%29221%20820%2007%2000" value="+492218200700" target="_blank">+49 (0)221 820 07 00
Fax : <a href="tel:%2B49%20%280%29221%20820%2007%2022" value="+492218200722" target="_blank">+49 (0)221 820 07 22
Mail: [hidden email]
Web : http://www.its-telco.de
----------------------------------------------------------------
Sitz der Gesellschaft: Köln
Amtsgericht Köln, HRB 59310
Geschäftsführer: Gunnar Haack, Ralf Petersilka, Michael Schnepf, Kai
Schriewer, Ludger Schulte
----------------------------------------------------------------

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der
richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese
E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the
intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in
this e-mail is strictly forbidden.

------------------------------------------------------------------------------
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel


------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel




--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Geosolutions' Winter Holidays from 24/12 to 6/1

Ing. Andrea Aime 
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549


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.


-------------------------------------------------------

------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

Ian Turton
I'd hate to reopen this can of worms - feel free to see https://github.com/geotools/geotools/pull/808https://github.com/geotools/geotools/pull/872https://github.com/geotools/geotools/pull/775 and probably more besides.

There is no good way to handle dates going into and out of the Databases we support without either forcing an explicit timezone or converting them to strings which makes filtering much harder.

Please be very careful if you do make any changes to make sure all the tests pass as is.

Ian

On 19 December 2015 at 07:09, Andrea Aime <[hidden email]> wrote:
Hi Jody,
there is indeed a chance this change will break CITE testing, however, we
are running a old and buggy version of it.
After six months of waiting for the new engine to be deployed on ares I've
honestly lost interest and gave up (others feel free to resume the effort), 
but if we ever do get stuff on there, this change should probably be revisited.

In particular, formatting the date with a Z ending it just seems out of spec,
dates do not seem to have a timezone specifier:

Unless of course the wikipedia page misses some information compared
to the actual full ISO8601 standard.

Now, to be honest, the notion of a date without a timezone is rather counter-intuitive 
to me (probably because I'm too used to work across a large span of timezones). 
Right now If you ask me what day it is, I'll say Saturday, but if we ask Jody, he'll say Friday (it's 8am
now in italy, but 11pm of the day before in Victoria, Canada). 
That is, to me, it does not make sense to talk about a date without a notion
of timezone... it would not even make sense to have a thing called the
international date line, a line that when crossed changes the current

Citing a fitting example from that page:
"Christmas, for example, is celebrated on 25 December (according to either the Gregorian or the Julian calendar, depending upon which of the two is used by the particular church) as that date falls in countries located on either side of the Date Line. Thus, whether it is Western Christmas or Orthodox Christmas, Christians in Samoa, immediately west of the Date Line, will celebrate the holiday a day before Christians in American Samoa, which is immediately east of the Date Line"

That said, I fully understand that storing a pure date in a database, and
have it changed by the GML output to the day before/after is
quite maddening, unless someone is really working in an international,
world wide, setting (at which point, they probably want to be more precise
and use full timestamps)

Maybe we should have some sort of way to control this behavior?

Cheers
Andrea


On Sat, Dec 19, 2015 at 1:52 AM, Jody Garnett <[hidden email]> wrote:
Hey Andreas, interesting discussion.

I just rejected a "workaround" (https://github.com/geotools/geotools/pull/997) on a similar topic - dealing with dates far in the past.

We tend to base our datastore / query / filter API off the WFS - in particular we may be able to check the OGC docs for clarification (or ask on the [hidden email] email list).

While your argument makes sense to me I would like to focus on interoperability if we can.


--
Jody Garnett

On 18 December 2015 at 03:44, Andreas Watermeyer <[hidden email]> wrote:
Hi GeoTools-Developers,

I recently created https://osgeo-org.atlassian.net/browse/GEOT-5329 to
propose a patch to change GeoTools java.sql.Date to String conversion
due to problems arising from timezones.

Andrea Aime suggested involve this mailing list.

Problem:
A date (without time) in Postgres (2015-12-18) is delivered to client
as 2015-12-17Z.
This occurs due to internal time zone conversion to GMT.

My understanding (from https://en.wikipedia.org/wiki/ISO_8601):
Dates (without time component) are not related to time zones. They are
unaware of time zones.

Additionally:
When talking about dates (without time), it does not matter, at which
*time* the day starts or ends, it is just a date (without time). That
means: People in Europe and Australia have same understanding of Jan
1st, but they have if different understand about when the day starts
or ends. But this is about times *not* about dates.

So, my suggestion is as follows:
A date (without time) should not be changed on transfer, no matter of
time zone boundaries.

Reason:
Dates are not time zone dependent. If somebody wants time zone
dependent behaviour, it is required to specify a date and time, not a
pure date.

In Java Objects:
Date (without time): java.sql.Date - shall be transferred unaware of time zones
Date (with time):  java.util.Date - shall be transferred using time
zone shifting
The proposed patch implements this concept.

In other words:
I think it is very unlikely, that anybody expects a date (without
time) to be shifted, because of time zone difference. Especially in
cases of a small offset of +/- 1h.
The current behaviour implies that GeoTools consumers treat dates
(without time) as timezone-aware date and time objects, transfer the
date and time into the local time zone and treat it as date again.

Note:
Unfortunately java.sql.Date is internally time-based, which is an
often criticized design decision and leads to constant confusion. I
think this is the actual reason for this issue.

One further aspect:
GeoTools currently formats dates as "2015-12-18Z", "Z" for time zone
UTC ("Zulu").
As far as I know this is required to be CITE compliant. Due to
https://en.wikipedia.org/wiki/ISO_8601 this is not a valid format for
dates (without time). But maybe wikipedia is incomplete.
I am not suggesting to change this behaviour, although it make no
sense, in my opinion.

Technical Conclusion:
The patch is based on the assumption, that java.sql.Date objects
should be treated as date  without time. Dates without time should not
be changed on transfer across time zone boundaries. Therefore
java.sql.Date shall be converted to a string reflecting the local
meaning. In the current implementation this means, that the time zone
offset has to be considered to neutralized time zone effects.

This is my point of view. I hoper the majority can follow my suggestion.

With best regards,

Andreas
----------------------------------------------------------------
ITS Telco Services GmbH
GIS Services & Solutions
Telecommunications Division
Dillenburger Str. 77
D-51105 Köln
Tel.: <a href="tel:%2B49%20%280%29221%20820%2007%2000" value="+492218200700" target="_blank">+49 (0)221 820 07 00
Fax : <a href="tel:%2B49%20%280%29221%20820%2007%2022" value="+492218200722" target="_blank">+49 (0)221 820 07 22
Mail: [hidden email]
Web : http://www.its-telco.de
----------------------------------------------------------------
Sitz der Gesellschaft: Köln
Amtsgericht Köln, HRB 59310
Geschäftsführer: Gunnar Haack, Ralf Petersilka, Michael Schnepf, Kai
Schriewer, Ludger Schulte
----------------------------------------------------------------

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der
richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese
E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the
intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in
this e-mail is strictly forbidden.

------------------------------------------------------------------------------
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel


------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel




--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Geosolutions' Winter Holidays from 24/12 to 6/1

Ing. Andrea Aime 
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: <a href="tel:%2B39%200584%20962313" value="+390584962313" target="_blank">+39 0584 962313
fax: <a href="tel:%2B39%200584%201660272" value="+3905841660272" target="_blank">+39 0584 1660272
mob: <a href="tel:%2B39%20%C2%A0339%208844549" value="+393398844549" target="_blank">+39  339 8844549


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.


-------------------------------------------------------

------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel




--
Ian Turton

------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

Andreas Watermeyer
Hi all,

thank you very much for your response.

I did some more research on this:

Most important: I was wrong, dates can be time zoned: http://www.w3.org/TR/xmlschema-2/#date. The XML spec for dates and times is inspired by ISO 8601. Both, the XML spec and ISO 8601 allow the time zone postfix "Z" for dates, according to http://www.cs.tut.fi/~jkorpela/iso8601.html.

On the other hand I am still convinced, that the vast majority of systems require a time zone unaware date handling. This is also reflected by GEOT-5025, GEOS-1235, GEOS-1161, GEOT-5025 (CITE tests fail depending on time zone).

My assumption is:
- either java.sql.Date users use GeoTools in an area with a timezone offset > 0, where the problem just does not exist
- the particular project has not even realized that dates are shifted by -1

But I can not imagine that anybody relies on the current implementation.

I currently see two possible solutions:

a) My proposal. But in this case the "Z" must be removed. Otherwise the date is considered time zoned, which is wrong. Without "Z" it is considered to be local, which would be correct.

b) Making the behaviour configurable (certainly the best choice). I dont know very much of GeoTools. What would be the way to go?

I could image to split the problem in two parts:
1) Support Java 8 Time API. By definition java.time.LocalDate has no time zone. It should be clear that such Date objects should be converted to strings without time zone.
2) Let the user control if a PostGIS date column should be published as java.sql.Date or java.time.LocalTime. I am unsure if JDBC can handle that out of the box, although it seems so (http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html)

I suppose that is not an easy solution and I am probably not the one to implement it, having not enough GeoTools know-how.

What do you think?

BTW: Is it possible to run the CITE tests against GeoServer/GeoTools easily? Maybe as part of the build? How?

Best regards,
Andreas


2015-12-19 12:28 GMT+01:00 Ian Turton <[hidden email]>:
I'd hate to reopen this can of worms - feel free to see https://github.com/geotools/geotools/pull/808https://github.com/geotools/geotools/pull/872https://github.com/geotools/geotools/pull/775 and probably more besides.

There is no good way to handle dates going into and out of the Databases we support without either forcing an explicit timezone or converting them to strings which makes filtering much harder.

Please be very careful if you do make any changes to make sure all the tests pass as is.

Ian

On 19 December 2015 at 07:09, Andrea Aime <[hidden email]> wrote:
Hi Jody,
there is indeed a chance this change will break CITE testing, however, we
are running a old and buggy version of it.
After six months of waiting for the new engine to be deployed on ares I've
honestly lost interest and gave up (others feel free to resume the effort), 
but if we ever do get stuff on there, this change should probably be revisited.

In particular, formatting the date with a Z ending it just seems out of spec,
dates do not seem to have a timezone specifier:

Unless of course the wikipedia page misses some information compared
to the actual full ISO8601 standard.

Now, to be honest, the notion of a date without a timezone is rather counter-intuitive 
to me (probably because I'm too used to work across a large span of timezones). 
Right now If you ask me what day it is, I'll say Saturday, but if we ask Jody, he'll say Friday (it's 8am
now in italy, but 11pm of the day before in Victoria, Canada). 
That is, to me, it does not make sense to talk about a date without a notion
of timezone... it would not even make sense to have a thing called the
international date line, a line that when crossed changes the current

Citing a fitting example from that page:
"Christmas, for example, is celebrated on 25 December (according to either the Gregorian or the Julian calendar, depending upon which of the two is used by the particular church) as that date falls in countries located on either side of the Date Line. Thus, whether it is Western Christmas or Orthodox Christmas, Christians in Samoa, immediately west of the Date Line, will celebrate the holiday a day before Christians in American Samoa, which is immediately east of the Date Line"

That said, I fully understand that storing a pure date in a database, and
have it changed by the GML output to the day before/after is
quite maddening, unless someone is really working in an international,
world wide, setting (at which point, they probably want to be more precise
and use full timestamps)

Maybe we should have some sort of way to control this behavior?

Cheers
Andrea


On Sat, Dec 19, 2015 at 1:52 AM, Jody Garnett <[hidden email]> wrote:
Hey Andreas, interesting discussion.

I just rejected a "workaround" (https://github.com/geotools/geotools/pull/997) on a similar topic - dealing with dates far in the past.

We tend to base our datastore / query / filter API off the WFS - in particular we may be able to check the OGC docs for clarification (or ask on the [hidden email] email list).

While your argument makes sense to me I would like to focus on interoperability if we can.


--
Jody Garnett

On 18 December 2015 at 03:44, Andreas Watermeyer <[hidden email]> wrote:
Hi GeoTools-Developers,

I recently created https://osgeo-org.atlassian.net/browse/GEOT-5329 to
propose a patch to change GeoTools java.sql.Date to String conversion
due to problems arising from timezones.

Andrea Aime suggested involve this mailing list.

Problem:
A date (without time) in Postgres (2015-12-18) is delivered to client
as 2015-12-17Z.
This occurs due to internal time zone conversion to GMT.

My understanding (from https://en.wikipedia.org/wiki/ISO_8601):
Dates (without time component) are not related to time zones. They are
unaware of time zones.

Additionally:
When talking about dates (without time), it does not matter, at which
*time* the day starts or ends, it is just a date (without time). That
means: People in Europe and Australia have same understanding of Jan
1st, but they have if different understand about when the day starts
or ends. But this is about times *not* about dates.

So, my suggestion is as follows:
A date (without time) should not be changed on transfer, no matter of
time zone boundaries.

Reason:
Dates are not time zone dependent. If somebody wants time zone
dependent behaviour, it is required to specify a date and time, not a
pure date.

In Java Objects:
Date (without time): java.sql.Date - shall be transferred unaware of time zones
Date (with time):  java.util.Date - shall be transferred using time
zone shifting
The proposed patch implements this concept.

In other words:
I think it is very unlikely, that anybody expects a date (without
time) to be shifted, because of time zone difference. Especially in
cases of a small offset of +/- 1h.
The current behaviour implies that GeoTools consumers treat dates
(without time) as timezone-aware date and time objects, transfer the
date and time into the local time zone and treat it as date again.

Note:
Unfortunately java.sql.Date is internally time-based, which is an
often criticized design decision and leads to constant confusion. I
think this is the actual reason for this issue.

One further aspect:
GeoTools currently formats dates as "2015-12-18Z", "Z" for time zone
UTC ("Zulu").
As far as I know this is required to be CITE compliant. Due to
https://en.wikipedia.org/wiki/ISO_8601 this is not a valid format for
dates (without time). But maybe wikipedia is incomplete.
I am not suggesting to change this behaviour, although it make no
sense, in my opinion.

Technical Conclusion:
The patch is based on the assumption, that java.sql.Date objects
should be treated as date  without time. Dates without time should not
be changed on transfer across time zone boundaries. Therefore
java.sql.Date shall be converted to a string reflecting the local
meaning. In the current implementation this means, that the time zone
offset has to be considered to neutralized time zone effects.

This is my point of view. I hoper the majority can follow my suggestion.

With best regards,

Andreas
----------------------------------------------------------------
ITS Telco Services GmbH
GIS Services & Solutions
Telecommunications Division
Dillenburger Str. 77
D-51105 Köln
Tel.: <a href="tel:%2B49%20%280%29221%20820%2007%2000" value="+492218200700" target="_blank">+49 (0)221 820 07 00
Fax : <a href="tel:%2B49%20%280%29221%20820%2007%2022" value="+492218200722" target="_blank">+49 (0)221 820 07 22
Mail: [hidden email]
Web : http://www.its-telco.de
----------------------------------------------------------------
Sitz der Gesellschaft: Köln
Amtsgericht Köln, HRB 59310
Geschäftsführer: Gunnar Haack, Ralf Petersilka, Michael Schnepf, Kai
Schriewer, Ludger Schulte
----------------------------------------------------------------

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der
richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese
E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the
intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in
this e-mail is strictly forbidden.

------------------------------------------------------------------------------
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel


------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel




--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Geosolutions' Winter Holidays from 24/12 to 6/1

Ing. Andrea Aime 
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: <a href="tel:%2B39%200584%20962313" value="+390584962313" target="_blank">+39 0584 962313
fax: <a href="tel:%2B39%200584%201660272" value="+3905841660272" target="_blank">+39 0584 1660272
mob: <a href="tel:%2B39%20%C2%A0339%208844549" value="+393398844549" target="_blank">+39  339 8844549


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.


-------------------------------------------------------

------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel




--
Ian Turton



--
Andreas Watermeyer
office: +49 (0)221 820 07 14
----------------------------------------------------------------
ITS Telco Services GmbH
GIS Services & Solutions
Telecommunications Division
Dillenburger Str. 77
D-51105 Köln
Tel.: +49 (0)221 820 07 00
Fax : +49 (0)221 820 07 22
Mail: [hidden email]
Web : http://www.its-telco.de
----------------------------------------------------------------
Sitz der Gesellschaft: Köln
Amtsgericht Köln, HRB 59310
Geschäftsführer: Gunnar Haack, Ralf Petersilka, Michael Schnepf, Kai Schriewer, Ludger Schulte
----------------------------------------------------------------

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

Peter Borissow
PostgreSQL has a several ways to store dates that might be problematic:

- timestamp without time zone
- date without a time of day.



Assuming we're limiting the scope to PostgreSQL with one of these column types:

(a) +1 for removing the "Z"

(b) +1 for remapping PostgreSQL date column to the new Java date classes:

 - timestamp without time zone --> java.time.LocalTime
 - date without a time of day --> java.time.LocalDate




From: Andreas Watermeyer <[hidden email]>
To: Ian Turton <[hidden email]>
Cc: geotools-devel <[hidden email]>
Sent: Monday, December 21, 2015 6:36 AM
Subject: Re: [Geotools-devel] GEOT-5329: Proposal to avoid Date-shifting due to Timezones

Hi all,

thank you very much for your response.

I did some more research on this:

Most important: I was wrong, dates can be time zoned: http://www.w3.org/TR/xmlschema-2/#date. The XML spec for dates and times is inspired by ISO 8601. Both, the XML spec and ISO 8601 allow the time zone postfix "Z" for dates, according to http://www.cs.tut.fi/~jkorpela/iso8601.html.

On the other hand I am still convinced, that the vast majority of systems require a time zone unaware date handling. This is also reflected by GEOT-5025, GEOS-1235, GEOS-1161, GEOT-5025 (CITE tests fail depending on time zone).

My assumption is:
- either java.sql.Date users use GeoTools in an area with a timezone offset > 0, where the problem just does not exist
- the particular project has not even realized that dates are shifted by -1

But I can not imagine that anybody relies on the current implementation.

I currently see two possible solutions:

a) My proposal. But in this case the "Z" must be removed. Otherwise the date is considered time zoned, which is wrong. Without "Z" it is considered to be local, which would be correct.

b) Making the behaviour configurable (certainly the best choice). I dont know very much of GeoTools. What would be the way to go?

I could image to split the problem in two parts:
1) Support Java 8 Time API. By definition java.time.LocalDate has no time zone. It should be clear that such Date objects should be converted to strings without time zone.
2) Let the user control if a PostGIS date column should be published as java.sql.Date or java.time.LocalTime. I am unsure if JDBC can handle that out of the box, although it seems so (http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html)

I suppose that is not an easy solution and I am probably not the one to implement it, having not enough GeoTools know-how.

What do you think?

BTW: Is it possible to run the CITE tests against GeoServer/GeoTools easily? Maybe as part of the build? How?

Best regards,
Andreas


2015-12-19 12:28 GMT+01:00 Ian Turton <[hidden email]>:
I'd hate to reopen this can of worms - feel free to see https://github.com/geotools/geotools/pull/808https://github.com/geotools/geotools/pull/872https://github.com/geotools/geotools/pull/775 and probably more besides.

There is no good way to handle dates going into and out of the Databases we support without either forcing an explicit timezone or converting them to strings which makes filtering much harder.

Please be very careful if you do make any changes to make sure all the tests pass as is.

Ian

On 19 December 2015 at 07:09, Andrea Aime <[hidden email]> wrote:
Hi Jody,
there is indeed a chance this change will break CITE testing, however, we
are running a old and buggy version of it.
After six months of waiting for the new engine to be deployed on ares I've
honestly lost interest and gave up (others feel free to resume the effort), 
but if we ever do get stuff on there, this change should probably be revisited.

In particular, formatting the date with a Z ending it just seems out of spec,
dates do not seem to have a timezone specifier:

Unless of course the wikipedia page misses some information compared
to the actual full ISO8601 standard.

Now, to be honest, the notion of a date without a timezone is rather counter-intuitive 
to me (probably because I'm too used to work across a large span of timezones). 
Right now If you ask me what day it is, I'll say Saturday, but if we ask Jody, he'll say Friday (it's 8am
now in italy, but 11pm of the day before in Victoria, Canada). 
That is, to me, it does not make sense to talk about a date without a notion
of timezone... it would not even make sense to have a thing called the
international date line, a line that when crossed changes the current

Citing a fitting example from that page:
"Christmas, for example, is celebrated on 25 December (according to either the Gregorian or the Julian calendar, depending upon which of the two is used by the particular church) as that date falls in countries located on either side of the Date Line. Thus, whether it is Western Christmas or Orthodox Christmas, Christians in Samoa, immediately west of the Date Line, will celebrate the holiday a day before Christians in American Samoa, which is immediately east of the Date Line"

That said, I fully understand that storing a pure date in a database, and
have it changed by the GML output to the day before/after is
quite maddening, unless someone is really working in an international,
world wide, setting (at which point, they probably want to be more precise
and use full timestamps)

Maybe we should have some sort of way to control this behavior?

Cheers
Andrea


On Sat, Dec 19, 2015 at 1:52 AM, Jody Garnett <[hidden email]> wrote:
Hey Andreas, interesting discussion.

I just rejected a "workaround" (https://github.com/geotools/geotools/pull/997) on a similar topic - dealing with dates far in the past.

We tend to base our datastore / query / filter API off the WFS - in particular we may be able to check the OGC docs for clarification (or ask on the [hidden email] email list).

While your argument makes sense to me I would like to focus on interoperability if we can.


--
Jody Garnett

On 18 December 2015 at 03:44, Andreas Watermeyer <[hidden email]> wrote:
Hi GeoTools-Developers,

I recently created https://osgeo-org.atlassian.net/browse/GEOT-5329 to
propose a patch to change GeoTools java.sql.Date to String conversion
due to problems arising from timezones.

Andrea Aime suggested involve this mailing list.

Problem:
A date (without time) in Postgres (2015-12-18) is delivered to client
as 2015-12-17Z.
This occurs due to internal time zone conversion to GMT.

My understanding (from https://en.wikipedia.org/wiki/ISO_8601):
Dates (without time component) are not related to time zones. They are
unaware of time zones.

Additionally:
When talking about dates (without time), it does not matter, at which
*time* the day starts or ends, it is just a date (without time). That
means: People in Europe and Australia have same understanding of Jan
1st, but they have if different understand about when the day starts
or ends. But this is about times *not* about dates.

So, my suggestion is as follows:
A date (without time) should not be changed on transfer, no matter of
time zone boundaries.

Reason:
Dates are not time zone dependent. If somebody wants time zone
dependent behaviour, it is required to specify a date and time, not a
pure date.

In Java Objects:
Date (without time): java.sql.Date - shall be transferred unaware of time zones
Date (with time):  java.util.Date - shall be transferred using time
zone shifting
The proposed patch implements this concept.

In other words:
I think it is very unlikely, that anybody expects a date (without
time) to be shifted, because of time zone difference. Especially in
cases of a small offset of +/- 1h.
The current behaviour implies that GeoTools consumers treat dates
(without time) as timezone-aware date and time objects, transfer the
date and time into the local time zone and treat it as date again.

Note:
Unfortunately java.sql.Date is internally time-based, which is an
often criticized design decision and leads to constant confusion. I
think this is the actual reason for this issue.

One further aspect:
GeoTools currently formats dates as "2015-12-18Z", "Z" for time zone
UTC ("Zulu").
As far as I know this is required to be CITE compliant. Due to
https://en.wikipedia.org/wiki/ISO_8601 this is not a valid format for
dates (without time). But maybe wikipedia is incomplete.
I am not suggesting to change this behaviour, although it make no
sense, in my opinion.

Technical Conclusion:
The patch is based on the assumption, that java.sql.Date objects
should be treated as date  without time. Dates without time should not
be changed on transfer across time zone boundaries. Therefore
java.sql.Date shall be converted to a string reflecting the local
meaning. In the current implementation this means, that the time zone
offset has to be considered to neutralized time zone effects.

This is my point of view. I hoper the majority can follow my suggestion.

With best regards,

Andreas
----------------------------------------------------------------
ITS Telco Services GmbH
GIS Services & Solutions
Telecommunications Division
Dillenburger Str. 77
D-51105 Köln
Tel.: +49 (0)221 820 07 00
Fax : +49 (0)221 820 07 22
Mail: [hidden email]
Web : http://www.its-telco.de
----------------------------------------------------------------
Sitz der Gesellschaft: Köln
Amtsgericht Köln, HRB 59310
Geschäftsführer: Gunnar Haack, Ralf Petersilka, Michael Schnepf, Kai
Schriewer, Ludger Schulte
----------------------------------------------------------------

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der
richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese
E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the
intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in
this e-mail is strictly forbidden.

------------------------------------------------------------------------------
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel


------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel




--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Geosolutions' Winter Holidays from 24/12 to 6/1

Ing. Andrea Aime 
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy


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.

-------------------------------------------------------

------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel




--
Ian Turton



--
Andreas Watermeyer
office: +49 (0)221 820 07 14
----------------------------------------------------------------
ITS Telco Services GmbH
GIS Services & Solutions
Telecommunications Division
Dillenburger Str. 77
D-51105 Köln
Tel.: +49 (0)221 820 07 00
Fax : +49 (0)221 820 07 22
Mail: [hidden email]
Web : http://www.its-telco.de
----------------------------------------------------------------
Sitz der Gesellschaft: Köln
Amtsgericht Köln, HRB 59310
Geschäftsführer: Gunnar Haack, Ralf Petersilka, Michael Schnepf, Kai Schriewer, Ludger Schulte
----------------------------------------------------------------

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel



------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

geowolf
In reply to this post by Andreas Watermeyer
On Mon, Dec 21, 2015 at 12:36 PM, Andreas Watermeyer <[hidden email]> wrote:
Hi all,

thank you very much for your response.

I did some more research on this:

Most important: I was wrong, dates can be time zoned: http://www.w3.org/TR/xmlschema-2/#date. The XML spec for dates and times is inspired by ISO 8601. Both, the XML spec and ISO 8601 allow the time zone postfix "Z" for dates, according to http://www.cs.tut.fi/~jkorpela/iso8601.html.

Interesting, thanks, this is good research.
 

On the other hand I am still convinced, that the vast majority of systems require a time zone unaware date handling. This is also reflected by GEOT-5025, GEOS-1235, GEOS-1161, GEOT-5025 (CITE tests fail depending on time zone).

I checked, the two still open are not referring to CITE tests, but to locally running the PostGIS online tests in the
jt-jdbc-postgis module, which were evidently developed with local dates in mind. 
CITE tests are for international conformance and in all likeliness demand timezoned
values (it's no doubt that OGC standards are developed and provide the full of of their value in international settings).
 

My assumption is:
- either java.sql.Date users use GeoTools in an area with a timezone offset > 0, where the problem just does not exist
- the particular project has not even realized that dates are shifted by -1

Hum... not really, the people that developed the JDBC modules and associated tests were living between UTC-8 and UTC+1,
while I believe the tickets still open were opened by people living in UTC+6 to UTC+8
 

But I can not imagine that anybody relies on the current implementation.

GeoServer is used a lot in international settings where the local date has
little meaning, spatial agencies, UN bodies, multinationals, are all examples of heavy GeoTools/GeoServer
users where the timezone locking is most important. They are also the entities that provide most of the sponsoring,
so it's not strange that there is a bias towards their use case (they directly contributed resources to have that work).

That does not mean we don't want the other use case to be implemented, on the contrary, we're just waiting
for resources to be put against that one, and be well locked down with a safety net of unit and integration test,
to ensure its continued support over time.
 

I currently see two possible solutions:

a) My proposal. But in this case the "Z" must be removed. Otherwise the date is considered time zoned, which is wrong. Without "Z" it is considered to be local, which would be correct.

Not acceptable, it would simply trade one use case for another.
 

b) Making the behaviour configurable (certainly the best choice). I dont know very much of GeoTools. What would be the way to go?

Yes, this is the way to go.
 

I could image to split the problem in two parts:
1) Support Java 8 Time API. By definition java.time.LocalDate has no time zone. It should be clear that such Date objects should be converted to strings without time zone.

This looks like a good idea, and it's good timing too, the GeoTools developer series just switched to Java 8, so we can start depending
on this new class. Mind, this approach means the change will be locked up to the current dev series (15.x, to be released as stable
in March 2016), cannot be backported to 14.x or 13.x, as those will have to keep on building with Java 7 until we dismiss them 
(13.x will be dropped in a few months, 14.x in September 2016).
 
2) Let the user control if a PostGIS date column should be published as java.sql.Date or java.time.LocalTime. I am unsure if JDBC can handle that out of the box, although it seems so (http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html)

That is probably well linked to the particular JDBC driver implementation used, I would try to avoid depending on it
as users can just switch around drivers (especially for proprietary databases). Best to get a java.sql.Date and convert
in code imho.
 

I suppose that is not an easy solution and I am probably not the one to implement it, having not enough GeoTools know-how.

What do you think?

I guess the common cases are that an installation/system is either fully local time based, or fully timezone aware, but I would
like to avoid making it impossible to have a system that has mixed date handling, e.g., a mostly local organization that
also happens to interact in small parts in international settings.

Thinking out loud, I can see three approaches to configuration:
a) Java System variable or GeoTools global hint (GeoTools.getDefaultHints()). Simple to code, works both read and write, 
    somewhat inflexible (all or nothing), somewhat harder to use for end users. 
b) Query hint (Query.getHints()). Allows to switch between local and timezoned views on a per request basis, downside, 
   there is no write support for it (and I guess we want to know if a date is timezone or not for writes too.. humm... we could
   just assume the value is timezoned unless it's a LocalTime though)
c) DataStore initialization parameter (see for example PostgisNGDataStoreFactory), that would make all feature types 
   of that store either local or timezoned, both read and write.

In all cases we'd default to timezoned values to maintain backwards compatibility.

Approach a) could be used to guard your current proposed changes, and have them kick in only if the variable
is set.
 

BTW: Is it possible to run the CITE tests against GeoServer/GeoTools easily? Maybe as part of the build? How?

Not easily, not as part of a normal build, as they require a GeoServer with a specific data set running (different
for each OGC standard and version) and a second tool, the CITE engine, running that will make interactive
requests to the OGC service being tested.

Setting up a tests to run locally is particularly convoluted (imho), I've setup a little project to automate part
of the process here:

Cheers
Andrea

--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Geosolutions' Winter Holidays from 24/12 to 6/1

Ing. Andrea Aime 
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549


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.


-------------------------------------------------------

------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

Andreas Watermeyer
Hi Andrea,

thank you very much for your detailed response.

I like your approach c) best because it is flexible enough and complete.

I try to sum up:

1) In future releases of GT FeatureTypes may have attributes of type
"LocalDate".
Question: Which parts of GT have to be adjusted in order to handle that?
- org.geotools.xml.XmlConverterFactory: Handle the LocalDate to String
conversion
- org.geotools.jdbc.JDBCDataStore: Create INSERTs, UPDATEs receiving
LocalDates, convert java.sql.Date to LocalDate when reading features
(depending on setup of DataStore). I suppose no changes are required
for queries.
- org.geotools.xs.bindings.XSDateBinding to handle String to LocalDate
conversion. I don't know the concepts behind GT XML parsing. How can
the binding consider the attribute type of a FeatureType?
- probably more ..?

2) GeoServer PostGIS DataStore configuration (UI & Backend) must be
enhanced to determine if a DataStore shall be treat date columns as
time zoned (default: time zoned). The DataStore and its delegates will
in turn create the respective FeatureType.

All of that must be backwards compatible.

I honestly don't know if I find the time to propose a pull request,
maybe on the long run. I will try if I can.

But first: Is everybody satisfied with the idea? Comments are welcome.

Best regards,
Andreas

------------------------------------------------------------------------------
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

geowolf
On Mon, Jan 4, 2016 at 11:00 AM, Andreas Watermeyer <[hidden email]> wrote:
Hi Andrea,

thank you very much for your detailed response.

I like your approach c) best because it is flexible enough and complete.

Yep, but also the most expensive to implement :-)
a) is a bit of hack indeed, but I believe it would get what you need with minimal
changes around your existing patch (still have to see if others would be ok
with it, I can say I'd be).
 

I try to sum up:

1) In future releases of GT FeatureTypes may have attributes of type
"LocalDate".
Question: Which parts of GT have to be adjusted in order to handle that?
- org.geotools.xml.XmlConverterFactory: Handle the LocalDate to String
conversion

Yes, that's correct, since LocalDate is not a java.util.Date
 
- org.geotools.jdbc.JDBCDataStore: Create INSERTs, UPDATEs receiving
LocalDates, convert java.sql.Date to LocalDate when reading features
(depending on setup of DataStore). I suppose no changes are required
for queries.

Unsure about queries, one should check  what happens with filter encoding,
probably add tests because if it works, it would be mostly by accident, rather
than design.
 
- org.geotools.xs.bindings.XSDateBinding to handle String to LocalDate
conversion. I don't know the concepts behind GT XML parsing. How can
the binding consider the attribute type of a FeatureType?

Havfe a look at how XSDateBinding coded and registered (gt-xsd-core), I guess we'd
need a XSLocalDateBinding. Yet, that would only cover GML 3+,
for GML2 we have a different (older but faster) parser/encoder, see FeatureTranslator
in gt-main
 
- probably more ..?

Eh yeah, if we consider both directions of data flow, we'd need to check the other
data stores as well (at least make sure they don't break if a LocalDate hits them),
and all the GeoServer WFS output formats too.
 

2) GeoServer PostGIS DataStore configuration (UI & Backend) must be
enhanced to determine if a DataStore shall be treat date columns as
time zoned (default: time zoned). The DataStore and its delegates will
in turn create the respective FeatureType.

All of that must be backwards compatible.

To some extent, but not fully, LocalDate is a Java 8 specific API, so
it would not be backportable to the stable and maintenace series.
 

I honestly don't know if I find the time to propose a pull request,
maybe on the long run. I will try if I can.

I agree it's a "high path" approach, better but expensive.
Personally I'd be ok with both a) and c)

Cheers
Andrea

--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Geosolutions' Winter Holidays from 24/12 to 6/1

Ing. Andrea Aime 
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549


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.


-------------------------------------------------------

------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

Peter Borissow
If backward compatibility is an issue, perhaps instead of using the new Java 8 classes, you can use a 3rd party library like Joda time:


They have a LocalDate, LocalTime, and LocalDateTime classes. Joda-Time is compatible with Java 5 and up.

Peter



From: Andrea Aime <[hidden email]>
To: Andreas Watermeyer <[hidden email]>
Cc: Ian Turton <[hidden email]>; geotools-devel <[hidden email]>
Sent: Monday, January 4, 2016 5:15 AM
Subject: Re: [Geotools-devel] GEOT-5329: Proposal to avoid Date-shifting due to Timezones

On Mon, Jan 4, 2016 at 11:00 AM, Andreas Watermeyer <[hidden email]> wrote:
Hi Andrea,

thank you very much for your detailed response.

I like your approach c) best because it is flexible enough and complete.

Yep, but also the most expensive to implement :-)
a) is a bit of hack indeed, but I believe it would get what you need with minimal
changes around your existing patch (still have to see if others would be ok
with it, I can say I'd be).
 

I try to sum up:

1) In future releases of GT FeatureTypes may have attributes of type
"LocalDate".
Question: Which parts of GT have to be adjusted in order to handle that?
- org.geotools.xml.XmlConverterFactory: Handle the LocalDate to String
conversion

Yes, that's correct, since LocalDate is not a java.util.Date
 
- org.geotools.jdbc.JDBCDataStore: Create INSERTs, UPDATEs receiving
LocalDates, convert java.sql.Date to LocalDate when reading features
(depending on setup of DataStore). I suppose no changes are required
for queries.

Unsure about queries, one should check  what happens with filter encoding,
probably add tests because if it works, it would be mostly by accident, rather
than design.
 
- org.geotools.xs.bindings.XSDateBinding to handle String to LocalDate
conversion. I don't know the concepts behind GT XML parsing. How can
the binding consider the attribute type of a FeatureType?

Havfe a look at how XSDateBinding coded and registered (gt-xsd-core), I guess we'd
need a XSLocalDateBinding. Yet, that would only cover GML 3+,
for GML2 we have a different (older but faster) parser/encoder, see FeatureTranslator
in gt-main
 
- probably more ..?

Eh yeah, if we consider both directions of data flow, we'd need to check the other
data stores as well (at least make sure they don't break if a LocalDate hits them),
and all the GeoServer WFS output formats too.
 

2) GeoServer PostGIS DataStore configuration (UI & Backend) must be
enhanced to determine if a DataStore shall be treat date columns as
time zoned (default: time zoned). The DataStore and its delegates will
in turn create the respective FeatureType.

All of that must be backwards compatible.

To some extent, but not fully, LocalDate is a Java 8 specific API, so
it would not be backportable to the stable and maintenace series.
 

I honestly don't know if I find the time to propose a pull request,
maybe on the long run. I will try if I can.

I agree it's a "high path" approach, better but expensive.
Personally I'd be ok with both a) and c)

Cheers
Andrea



------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

geowolf
On Mon, Jan 4, 2016 at 4:51 PM, Peter Borissow <[hidden email]> wrote:
If backward compatibility is an issue, perhaps instead of using the new Java 8 classes, you can use a 3rd party library like Joda time:


They have a LocalDate, LocalTime, and LocalDateTime classes. Joda-Time is compatible with Java 5 and up.

That is also an option but... we are trying to avoid adding more dependencies on core moules, if not strictly necessary, as the
library has grown too large enough (if anything, we should be looking into dropping some).
Anyways, it's open to debate.

Cheers
Andrea


--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Geosolutions' Winter Holidays from 24/12 to 6/1

Ing. Andrea Aime 
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549


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.


-------------------------------------------------------

------------------------------------------------------------------------------

_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

Andreas Watermeyer
In reply to this post by geowolf
Hi all,

I'd like to come back to this topic once more, see below.

2016-01-04 11:15 GMT+01:00 Andrea Aime <[hidden email]>:
> On Mon, Jan 4, 2016 at 11:00 AM, Andreas Watermeyer
> <[hidden email]> wrote:
>
> Yep, but also the most expensive to implement :-)
> a) is a bit of hack indeed, but I believe it would get what you need with
> minimal
> changes around your existing patch (still have to see if others would be ok
> with it, I can say I'd be).
>

Andrea suggests as a quick solution to enhance my proposed patch.

My patch neutralizes the shifting of dates through time zones by
considering the time zone offset.
This might be correct for some systems (local setups) while it might
be wrong for others (international setups).

The idea is to introduce a switch (GeoTools.getDefaultHints()) to
conditional enable/disable the patch.
By default it is disabled and therefore backwards compatible.

This patch only affects the java.sql.Date to String conversion
(org.geotools.xml.XmlConverterFactory).

@Everybody: What do you think? Is this a feasible solution?

Any suggestions for the name of the hint? Maybe
- JAVA_SQL_DATE_IGNORE_TIMEZONES: quite specific to this particular patch.
- LOCAL_DATE_TIME_HANDLING: More general. Might also be considered
globally when implementation the flexible solution later on.
- ...

Please note that GeoServer has already been changed using my original
patch, as I mentioned earlier (see GEOS-6777).
GeoServer uses a subclass of a GeoTools class:
org.geoserver.wfs.xml.xs.DateBinding. I suppose the subclass exists
for historical reasons (?) and can be dropped/cleared once this is
solved. If this is not going to be solved, the GS change should be
rolled back to be consistent IMHO.

Best regards,
Andreas

------------------------------------------------------------------------------
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

jody.garnett
Just want to follow up Andreas; your pull request has been a subject of discussion for each of the last two geotools meetings.

Is this something you could have ready before the code freeze? Or should we stop pestering you ...

--
Jody Garnett

On 5 January 2016 at 06:14, Andreas Watermeyer <[hidden email]> wrote:
Hi all,

I'd like to come back to this topic once more, see below.

2016-01-04 11:15 GMT+01:00 Andrea Aime <[hidden email]>:
> On Mon, Jan 4, 2016 at 11:00 AM, Andreas Watermeyer
> <[hidden email]> wrote:
>
> Yep, but also the most expensive to implement :-)
> a) is a bit of hack indeed, but I believe it would get what you need with
> minimal
> changes around your existing patch (still have to see if others would be ok
> with it, I can say I'd be).
>

Andrea suggests as a quick solution to enhance my proposed patch.

My patch neutralizes the shifting of dates through time zones by
considering the time zone offset.
This might be correct for some systems (local setups) while it might
be wrong for others (international setups).

The idea is to introduce a switch (GeoTools.getDefaultHints()) to
conditional enable/disable the patch.
By default it is disabled and therefore backwards compatible.

This patch only affects the java.sql.Date to String conversion
(org.geotools.xml.XmlConverterFactory).

@Everybody: What do you think? Is this a feasible solution?

Any suggestions for the name of the hint? Maybe
- JAVA_SQL_DATE_IGNORE_TIMEZONES: quite specific to this particular patch.
- LOCAL_DATE_TIME_HANDLING: More general. Might also be considered
globally when implementation the flexible solution later on.
- ...

Please note that GeoServer has already been changed using my original
patch, as I mentioned earlier (see GEOS-6777).
GeoServer uses a subclass of a GeoTools class:
org.geoserver.wfs.xml.xs.DateBinding. I suppose the subclass exists
for historical reasons (?) and can be dropped/cleared once this is
solved. If this is not going to be solved, the GS change should be
rolled back to be consistent IMHO.

Best regards,
Andreas


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

geowolf
In reply to this post by Andreas Watermeyer
Hi Andreas,
sorry, completely missed this mail of yours.

On Tue, Jan 5, 2016 at 3:14 PM, Andreas Watermeyer <[hidden email]> wrote:
@Everybody: What do you think? Is this a feasible solution?

+1 for me
 

Any suggestions for the name of the hint? Maybe
- JAVA_SQL_DATE_IGNORE_TIMEZONES: quite specific to this particular patch.
- LOCAL_DATE_TIME_HANDLING: More general. Might also be considered
globally when implementation the flexible solution later on.

I'd use the second one.
 
- ...

Please note that GeoServer has already been changed using my original
patch, as I mentioned earlier (see GEOS-6777).
GeoServer uses a subclass of a GeoTools class:
org.geoserver.wfs.xml.xs.DateBinding. I suppose the subclass exists
for historical reasons (?) and can be dropped/cleared once this is
solved. If this is not going to be solved, the GS change should be
rolled back to be consistent IMHO.

Which brings me to Jody's question. 
If your change does not make it in time for the feature freeze (in 5 days from
now) we should revert, otherwise if it does... should your patch be controlled
by the same system hint?

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


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.


-------------------------------------------------------

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

Andreas Watermeyer
Hi all,

I am currently quite busy, but I really like to see this solved, too.
I also appreciate your support so I will give it a try right now.
I hope it will not break other things, so close before code freeze.
It would be nice if somebody somebody could help me if I have question
regarding the start up parameters.

> now) we should revert, otherwise if it does... should your patch be
> controlled
> by the same system hint?
Yes, I will also provide a PR for that issue, introducing the same
guard condition.
I suppose a new SNAPSHOT of GT has to be available in order to be able
to use the new constant in GS.
Is a new SNAPSHOT released every night? Is it possible to release a
SNAPSHOT manually?

Best regards,
Andreas


2016-02-13 10:49 GMT+01:00 Andrea Aime <[hidden email]>:

> Hi Andreas,
> sorry, completely missed this mail of yours.
>
> On Tue, Jan 5, 2016 at 3:14 PM, Andreas Watermeyer
> <[hidden email]> wrote:
>>
>> @Everybody: What do you think? Is this a feasible solution?
>
>
> +1 for me
>
>>
>>
>> Any suggestions for the name of the hint? Maybe
>> - JAVA_SQL_DATE_IGNORE_TIMEZONES: quite specific to this particular patch.
>> - LOCAL_DATE_TIME_HANDLING: More general. Might also be considered
>> globally when implementation the flexible solution later on.
>
>
> I'd use the second one.
>
>>
>> - ...
>>
>> Please note that GeoServer has already been changed using my original
>> patch, as I mentioned earlier (see GEOS-6777).
>> GeoServer uses a subclass of a GeoTools class:
>> org.geoserver.wfs.xml.xs.DateBinding. I suppose the subclass exists
>> for historical reasons (?) and can be dropped/cleared once this is
>> solved. If this is not going to be solved, the GS change should be
>> rolled back to be consistent IMHO.
>
>
> Which brings me to Jody's question.
> If your change does not make it in time for the feature freeze (in 5 days
> from
> now) we should revert, otherwise if it does... should your patch be
> controlled
> by the same system hint?
>
> 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://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.
>
>
> -------------------------------------------------------



--
Andreas Watermeyer
office: +49 (0)221 820 07 14
----------------------------------------------------------------
ITS Telco Services GmbH
GIS Services & Solutions
Telecommunications Division
Dillenburger Str. 77
D-51105 Köln
Tel.: +49 (0)221 820 07 00
Fax : +49 (0)221 820 07 22
Mail: [hidden email]
Web : http://www.its-telco.de
----------------------------------------------------------------
Sitz der Gesellschaft: Köln
Amtsgericht Köln, HRB 59310
Geschäftsführer: Gunnar Haack, Ralf Petersilka, Michael Schnepf, Kai
Schriewer, Ludger Schulte
----------------------------------------------------------------

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der
richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese
E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the
intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in
this e-mail is strictly forbidden.

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

geowolf
On Mon, Feb 15, 2016 at 9:21 AM, Andreas Watermeyer <[hidden email]> wrote:
Hi all,

I am currently quite busy, but I really like to see this solved, too.
I also appreciate your support so I will give it a try right now.
I hope it will not break other things, so close before code freeze.
It would be nice if somebody somebody could help me if I have question
regarding the start up parameters.

It's going to be a busy week for everybody (people wake up when they hear
"feature freeze" and suddenly remember those things they need to get in 
since a months ago :-p), but ask away, we'll see what we can do :-)
 

> now) we should revert, otherwise if it does... should your patch be
> controlled
> by the same system hint?
Yes, I will also provide a PR for that issue, introducing the same
guard condition.
I suppose a new SNAPSHOT of GT has to be available in order to be able
to use the new constant in GS.
Is a new SNAPSHOT released every night? Is it possible to release a
SNAPSHOT manually?

Nightly builds are released daily out of code already merged into the branch.
But also feel free to build a snapshot of yours and make it available for
download for others to try out

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


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.


-------------------------------------------------------

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

Andreas Watermeyer
Hi all,

I have created a new pull request for this topic consisting of one commit only.

Regarding the GeoServer part (sort of cross-posting):

I will create a corresponding pull request. The GeoServer implementation (org.geoserver.wfs.xml.xs.DateBinding) is a subclass of the GeoTools implementation (org.geotools.xs.bindings.XSDateBinding, one of the classes changed by me). I see no reason for its existence. Maybe for historical reasons? I will just delete it and amend the registration code bringing it into play (org.geoserver.wfs.xml.v1_1_0.WFSConfiguration).

Ok?

Best regards,
Andreas

2016-02-15 9:30 GMT+01:00 Andrea Aime <[hidden email]>:
On Mon, Feb 15, 2016 at 9:21 AM, Andreas Watermeyer <[hidden email]> wrote:
Hi all,

I am currently quite busy, but I really like to see this solved, too.
I also appreciate your support so I will give it a try right now.
I hope it will not break other things, so close before code freeze.
It would be nice if somebody somebody could help me if I have question
regarding the start up parameters.

It's going to be a busy week for everybody (people wake up when they hear
"feature freeze" and suddenly remember those things they need to get in 
since a months ago :-p), but ask away, we'll see what we can do :-)
 

> now) we should revert, otherwise if it does... should your patch be
> controlled
> by the same system hint?
Yes, I will also provide a PR for that issue, introducing the same
guard condition.
I suppose a new SNAPSHOT of GT has to be available in order to be able
to use the new constant in GS.
Is a new SNAPSHOT released every night? Is it possible to release a
SNAPSHOT manually?

Nightly builds are released daily out of code already merged into the branch.
But also feel free to build a snapshot of yours and make it available for
download for others to try out

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: <a href="tel:%2B39%200584%20962313" value="+390584962313" target="_blank">+39 0584 962313
fax: <a href="tel:%2B39%200584%201660272" value="+3905841660272" target="_blank">+39 0584 1660272
mob: <a href="tel:%2B39%20%C2%A0339%208844549" value="+393398844549" target="_blank">+39  339 8844549


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.


-------------------------------------------------------



--
Andreas Watermeyer
office: +49 (0)221 820 07 14
----------------------------------------------------------------
ITS Telco Services GmbH
GIS Services & Solutions
Telecommunications Division
Dillenburger Str. 77
D-51105 Köln
Tel.: +49 (0)221 820 07 00
Fax : +49 (0)221 820 07 22
Mail: [hidden email]
Web : http://www.its-telco.de
----------------------------------------------------------------
Sitz der Gesellschaft: Köln
Amtsgericht Köln, HRB 59310
Geschäftsführer: Gunnar Haack, Ralf Petersilka, Michael Schnepf, Kai Schriewer, Ludger Schulte
----------------------------------------------------------------

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

Andreas Watermeyer
In reply to this post by geowolf
Could please anybody review the changes?

Best regards,
Andreas


2016-02-15 9:30 GMT+01:00 Andrea Aime <[hidden email]>:
On Mon, Feb 15, 2016 at 9:21 AM, Andreas Watermeyer <[hidden email]> wrote:
Hi all,

I am currently quite busy, but I really like to see this solved, too.
I also appreciate your support so I will give it a try right now.
I hope it will not break other things, so close before code freeze.
It would be nice if somebody somebody could help me if I have question
regarding the start up parameters.

It's going to be a busy week for everybody (people wake up when they hear
"feature freeze" and suddenly remember those things they need to get in 
since a months ago :-p), but ask away, we'll see what we can do :-)
 

> now) we should revert, otherwise if it does... should your patch be
> controlled
> by the same system hint?
Yes, I will also provide a PR for that issue, introducing the same
guard condition.
I suppose a new SNAPSHOT of GT has to be available in order to be able
to use the new constant in GS.
Is a new SNAPSHOT released every night? Is it possible to release a
SNAPSHOT manually?

Nightly builds are released daily out of code already merged into the branch.
But also feel free to build a snapshot of yours and make it available for
download for others to try out

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: <a href="tel:%2B39%200584%20962313" value="+390584962313" target="_blank">+39 0584 962313
fax: <a href="tel:%2B39%200584%201660272" value="+3905841660272" target="_blank">+39 0584 1660272
mob: <a href="tel:%2B39%20%C2%A0339%208844549" value="+393398844549" target="_blank">+39  339 8844549


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.


-------------------------------------------------------



--
Andreas Watermeyer
office: +49 (0)221 820 07 14
----------------------------------------------------------------
ITS Telco Services GmbH
GIS Services & Solutions
Telecommunications Division
Dillenburger Str. 77
D-51105 Köln
Tel.: +49 (0)221 820 07 00
Fax : +49 (0)221 820 07 22
Mail: [hidden email]
Web : http://www.its-telco.de
----------------------------------------------------------------
Sitz der Gesellschaft: Köln
Amtsgericht Köln, HRB 59310
Geschäftsführer: Gunnar Haack, Ralf Petersilka, Michael Schnepf, Kai Schriewer, Ludger Schulte
----------------------------------------------------------------

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOT-5329: Proposal to avoid Date-shifting due to Timezones

jody.garnett
Thank you for your prompt response. Reviewing now.

--
Jody Garnett

On 16 February 2016 at 02:54, Andreas Watermeyer <[hidden email]> wrote:
Could please anybody review the changes?

Best regards,
Andreas


2016-02-15 9:30 GMT+01:00 Andrea Aime <[hidden email]>:
On Mon, Feb 15, 2016 at 9:21 AM, Andreas Watermeyer <[hidden email]> wrote:
Hi all,

I am currently quite busy, but I really like to see this solved, too.
I also appreciate your support so I will give it a try right now.
I hope it will not break other things, so close before code freeze.
It would be nice if somebody somebody could help me if I have question
regarding the start up parameters.

It's going to be a busy week for everybody (people wake up when they hear
"feature freeze" and suddenly remember those things they need to get in 
since a months ago :-p), but ask away, we'll see what we can do :-)
 

> now) we should revert, otherwise if it does... should your patch be
> controlled
> by the same system hint?
Yes, I will also provide a PR for that issue, introducing the same
guard condition.
I suppose a new SNAPSHOT of GT has to be available in order to be able
to use the new constant in GS.
Is a new SNAPSHOT released every night? Is it possible to release a
SNAPSHOT manually?

Nightly builds are released daily out of code already merged into the branch.
But also feel free to build a snapshot of yours and make it available for
download for others to try out

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: <a href="tel:%2B39%200584%20962313" value="+390584962313" target="_blank">+39 0584 962313
fax: <a href="tel:%2B39%200584%201660272" value="+3905841660272" target="_blank">+39 0584 1660272
mob: <a href="tel:%2B39%20%C2%A0339%208844549" value="+393398844549" target="_blank">+39  339 8844549


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.


-------------------------------------------------------



--
Andreas Watermeyer
office: +49 (0)221 820 07 14
----------------------------------------------------------------
ITS Telco Services GmbH
GIS Services & Solutions
Telecommunications Division
Dillenburger Str. 77
D-51105 Köln
Tel.: +49 (0)221 820 07 00
Fax : +49 (0)221 820 07 22
Mail: [hidden email]
Web : http://www.its-telco.de
----------------------------------------------------------------
Sitz der Gesellschaft: Köln
Amtsgericht Köln, HRB 59310
Geschäftsführer: Gunnar Haack, Ralf Petersilka, Michael Schnepf, Kai Schriewer, Ludger Schulte
----------------------------------------------------------------

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel