Hello, the last days I have spent with an update of the GeoServer of our company, where I noticed some peculiarities with some code snippets of the GeoTools implementation, which is used by the GeoServer and our program to send features via WFS between our Oracle SQL databases and our program. I refer to the method parseObject() in the XsDateTimeFormat class in org.geotools.xml.impl in gt-xml-21.1.jar. In summary, this method is responsible for converting timestamps and dates from given Strings back to a Calendar object.
The first thing I noticed was that the attached time zone is also evaluated in this process. The ISO 8601 guideline provides four possibilities to specify a time zone, which are all accepted by the Java method TimeZone.getTimeZone(String ID), where the built string will be passed afterwards. Here are examples from the Wikipedia entry of ISO 8601 https://en.wikipedia.org/wiki/ISO_8601 : 1. <time>Z 2. <time>±hh:mm 3. <time>±hhmm 4. <time>±hh GeoTools can handle all the possibilities except the third, as you can see in the following code snippets: digits.setLength(0); digits.append("GMT"); if (offset < length) { char c = pString.charAt(offset); if (c == 'Z') { // Ignore UTC, it is the default ++offset; } else if (c == '+' || c == '-') { digits.append(c); ++offset; for (int i = 0; i < 5; i++) { if (offset >= length) { pParsePosition.setErrorIndex(offset); return null; } c = pString.charAt(offset); if ((i != 2 && Character.isDigit(c)) || (i == 2 && c == ':')) { digits.append(c); } else { pParsePosition.setErrorIndex(offset); return null; } ++offset; } } } For example, if the time zone is +0200, GeoTools will recognize the +02, but then expect a ":". If this does not happen, the evaluation is aborted and the time zone is assumed to be UTC. Wouldn't it be useful if this could still be modified so that such time zones could also be recognized? What do you think? Secondly, I noticed that the ISO 8601 standard says that if no time zone is specified, the time or date is assumed to be the local time zone. But if no time zone is specified, GeoTools always assumes that it is UTC. This causes incorrect convertings, when our program with GeoTools requests features from a deegree server via WFS for example. Because the deegree server does not convert the times to UTC before and does not append a time zone, GeoTools in our program always assumes that these times are UTC and add 2 more hours, because we are in UTC+2. Wouldn't it be beneficial if GeoTools would orientate itself a bit more on the ISO standards in this case and doesn't even try to convert time data without a time zone? Or what do you think of a setting possibility with which GeoTools can be told that also time data should not be converted and GeoTools assume that it must be a local time? The same possibility already exists with localDateTimeHandling=true for java.util.Date. But Timestamps in an SQL database are childs of java.sql.Date, which is unfortunately not effected of localDateTimeHandling. I'm looking forward to hearing your opinions. Or maybe there are already solutions for my problems, which I just haven't encountered yet? Many thanks already! Best Regards Falko
_______________________________________________ GeoTools-GT2-Users mailing list GeoTools-GT2-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
