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
