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 <andrea.a...@geo-solutions.it>: > On Mon, Jan 4, 2016 at 11:00 AM, Andreas Watermeyer > <andreas.waterme...@its-telco.de> 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 GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
