Its always one thing or another with dates and times isn't it...
As a 4th alternative:
How about always carrying around the date as a Calendar. As soon as the
date comes out of the jdbc driver convert to calendar ( am I correct in
assuming there is no loss of timezone here? ). Then have the mapping to
the correct xs:date, xs:datetime, etc... be done by the xml encoder /
geoserver type mapping. I guess this only works for the new xml encoder
though, not for old gml2 encoder.
As for the other alternatives, I think I like using a time library the
best.
Question: If we use joda can we get rid of jaxb? If so it might just be
worth it.
-Justin
Andrea Aime wrote:
> Hi,
> I'm trying to get our date/time support story more consistent,
> and I'm stumbling in a couple of road blocks I'd like to
> discuss.
>
> First a little introduction. Up to some time ago, geotools/geoserver
> date/time support was quite in disarray. Everything was managed as
> a java.util.Date, losing completely the distinction between Date, Time
> and Timestamp, which is necessary for good xml encoding (xs:date,
> xs:time, xs:datetime are different kind of beast).
>
> To keep the distinction around, I hacked the jdbc datastore to keep
> on using the sql type, which has the distinction, trying to force
> this kind of mapping:
> xs:datetime -> java.util.Date or java.sql.Timestamp
> xs:date -> java.sql.Date
> xs:time -> java.sql.Time
>
> So far so good, but there is still an issue: the timezone.
> Calendar seems to be the only class that properly carries around
> the timezone, whilst the other classes switch to the current
> timezone (the "global time" remains the same, but it's adjusted
> to the current timezone).
>
> For example, running the following small java app (requires jaxb in
> the path for ISO date/time formatting):
>
> import java.util.Calendar;
> import javax.xml.bind.DatatypeConverter;
> import com.sun.xml.bind.DatatypeConverterImpl;
> public class TimeTest {
> public static void main(String[] args) {
> DatatypeConverter.setDatatypeConverter(DatatypeConverterImpl.theInstance);
> Calendar calendar =
> DatatypeConverter.parseDateTime("2006-02-27T22:08:12+00:00");
> System.out.println(DatatypeConverter.printDateTime(calendar));
> Calendar c = Calendar.getInstance();
> java.util.Date date = calendar.getTime();
> System.out.println(date);
> c.setTime(date);
> System.out.println(DatatypeConverter.printDateTime(c));
> java.sql.Date sqlDate = new java.sql.Date(date.getTime());
> c.setTime(sqlDate);
> System.out.println(DatatypeConverter.printDateTime(c));
> }
> }
>
> on an italian system I get the following:
>
> 2006-02-27T22:08:12+00:00
> Mon Feb 27 23:08:12 CET 2006
> 2006-02-27T23:08:12+01:00
> 2006-02-27T23:08:12+01:00
>
> (CET being Central European Time). Notice how 22 turned to 23 and
> the time zone changed from +00 to +01.
>
> 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)
>
> The first one is to be checked, but I don't like it because it would
> introduce another heavy dependency (joda time jar is around 500kb),
> and we would have to fix all datastores to use it instead.
>
> The third one is easy, but it may not work all too well in web
> applications, since the system variable setup would be container wide
> (anyone knows if in common containers is possible to configure
> system variables per-application instead of per-VM?).
>
> The second one seems to strike a nice balance.
>
> Comments, suggestions? Speak up please :)
> Cheers
> Andrea
>
> -------------------------------------------------------------------------
> 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/
> _______________________________________________
> Geoserver-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> !DSPAM:4007,470b477e285954901796417!
>
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
-------------------------------------------------------------------------
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
