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