Justin's solution seems the most elegant - i.e. this is simply an encoding
issue at both the source and XML output end.
The other option we have in the community-schemas stuff is to bind a node to
a specfic data type, which is something we will _always_ need to do where
schemas use generic types but we want to implement a specifi type (eg a
numerical date positon, not a period, or even the name of a era "Jurassic"
for a GM_TimeObject).
Given the need for that capability, I'd vote against doing too much on a
type-specific hack just now, but moving to the most capable generic type (eg
Calendar - though I'm not too expert in its use I admit) makes sense.
The other thing to think about of course is profiling performance - we know
that time will be a heavily used attribute, with very large numbers of
results when handling time-series, and nearly always used as a query axis in
those case.
For myself, I would suggest we live with the ugly limitations of date in 2.4,
and would push for a proper solution on trunk rather than a lot of effort on
2.4 which will just delay and derail the real progress required.
i.e. perhaps Andreas solution #3 will work for 2.4 - its a system wide
config, for expert users, with a proper solution in the pipeline.
I think we would be kidding ourselves that a lot of work on a specific case
is not going to result in making the next step less stable.
Rob
On 10/10/07, Justin Deoliveira <[EMAIL PROTECTED]> wrote:
>
> 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
>
-------------------------------------------------------------------------
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
