Rob Atkinson ha scritto: > Justin's solution seems the most elegant - i.e. this is simply an > encoding issue at both the source and XML output end.
I agree it's elegant not too sure I'd call it a pure xml encoding issue thought. People are going to use those Calendar objects to build applications (since that's what we're going to have inside the Features). Using the java.util.Date hierarchy has the advantage of being familiar to most java programmers (more familiar than Calendar, that is). I also have the feeling that doing resultSet.getObject(xxx) on a time column will return a java.sql.Time, if it does, then the original timezone information is lost anyways on databases. This hibernate article seems to suggest so: http://www.hibernate.org/100.html That is, the impression is that you can do things so that you read date/time/timestamp in whatever timezone you want, but you can't get to know what the db timezone is. I'll investigate further during the weekend. Even if this cuts off databases, keeping around the timezone information can be worthy in the case of cascaded WFS, where we get to parse the XML and thus retain the original timezone info if using Calendar objects. > 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 believe it is. Yet, it seems I failed to convey the difference between a short term solution that can be done now, and a long term solution that I fear won't be applied at all unless there is specific funding for it. There is no sponsoring behind this topic, it's just something I felt was important because it's one of the basics we don't get right. Then again, the general consensus seems to be to go for the clean way. I hope we'll have the resources (and will) to address it in the not too distant future, in other words, that it does not become another GeoAPI filter thing (everybody agrees we should clean up the code base from the old filters, yet nobody is doing anything about it because it's too much work). > 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. Not sure I understand? :) 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/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
