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 [email protected] 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 < [email protected]> 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: [email protected] > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel >
------------------------------------------------------------------------------
_______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
