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:
http://joda-time.sourceforge.net/quickstart.html
They have a LocalDate, LocalTime, and LocalDateTime classes. Joda-Time is
compatible with Java 5 and up.
Peter
From: Andrea Aime <andrea.a...@geo-solutions.it>
To: Andreas Watermeyer <andreas.waterme...@its-telco.de>
Cc: Ian Turton <ijtur...@gmail.com>; geotools-devel
<geotools-devel@lists.sourceforge.net>
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
<andreas.waterme...@its-telco.de> 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 minimalchanges around your
existing patch (still have to see if others would be okwith 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, ratherthan 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'dneed a XSLocalDateBinding. Yet, that would only cover GML 3+,for GML2 we
have a different (older but faster) parser/encoder, see FeatureTranslatorin
gt-main
- probably more ..?
Eh yeah, if we consider both directions of data flow, we'd need to check the
otherdata 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, soit 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)
CheersAndrea
------------------------------------------------------------------------------
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
