On Mon, Dec 21, 2015 at 12:36 PM, Andreas Watermeyer < [email protected]> 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: https://github.com/geoserver/geoserver-cite-tools/tree/te-2015 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 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. -------------------------------------------------------
------------------------------------------------------------------------------
_______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
