Re: [Geotools-devel] [Geoserver-devel] More issues with date/time data types

[Andrea A. <aa...@op...>]

Justin Deoliveira ha scritto:
> 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.

I think we can do that, but we would need to create new attribute types,
TemporalAttributeType is just too generic (or as an alternative, have a
subtype information as a field). Then we would need to change the
AttributeTypeFactory.newAttributeType to allow a way to specify
the date/time flavour.
Finally all datastores should be updated as a consequence.
Also consider I'm talking of changes to be performed against gt2 2.4.x.

> 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.

I'm under the impression you're using at least another jaxb class... was
it something to handle namespaces? I just can't rember.
Yes, it seem Joda can handle those formats, at least there
is an XStream extension converter that uses it to handle ISO 8601
formats, see here: http://jira.codehaus.org/browse/XSTR-116

The other thing is that using Joda time classes we would make gt2-main
depend on it (the feature model is there), and that would be a new
and sizeable dependency. What do gt2 developers think?
In any case, it seems to me that such a sizeable switch could be
performed on trunk, but not in an RC of 2.4.x...
That's why I was sponsoring option 2, it requires very few changes ;)

Cheers
Andrea