Matthias Basler wrote: > Andrea Aime wrote: > >> Now, how do we handle this? The timezone does not seem to go thru from >> storage to XML encoding (and oh, btw, dbms are timezone aware). >> I see three ways: >> * find some classes that do keep the timezone intact. Maybe Joda time >> (http://joda-time.sourceforge.net/) can do this. >> * accept the loss, and allow the xml encoder to be configured with a >> target timezone (something we can do by injecting a timezone into >> the xml date/time bindings) >> * just use the default timezone, if someone needs a different one, >> he can configure the JVM accordingly using user.timezone >> (see >> http://www.javaworld.com/javaworld/jw-10-2003/jw-1003-time.html?page=4) >> [...] >> Comments, suggestions? Speak up please :) > > Introducing a heavy dependency doesn't sound good for a problem as simple as > this one. Still, if a timezone is provided and relevant it should not be lost > imho. > > So my solution would be to create a simple utility wrapper class that contains > - a flag that's telling whether Date, time or both are relevant > - the actual point in time (represented as java.util.Date) > (If only time is relevant then use today, it won't matter if > hash() is implemented correctly. If only day is relevant, use noon.) > - a timezone (represented as java.util.TimeZone) > (If not specified, set to the JVM's local one.) > > Pro: > - no additional dependency needed > - consistent handling of all SQL types > - can be extended to store more information if necessary > (e.g. date/time display format...) > - can contain conversion methods from/to SQL types, > so everything is in one spot. > > Contra: > - Will probably require lots of changes in source code > - When getting such class as parameter, it is not obvious > if it contains date, time or both. > - Users possibly wondering why they get an unfamilar wrapper class where they > expect a plain java.util.Date etc. But this can be documented. > > Maybe another solution already exists and is not 500kB fat? > Don't know. > > Just my 2c.
If GeoTools/GeoAPI try to implement some GI ISO standards then introducing a dirty wrapper around nonelegant old classes without future, doesn't sound good for me. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Filip Okal e-mail: [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
