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. -- Matthias Basler [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
