Hi Falko,

for local time there is no mechanism to handle the geeric case.  The
concept of Loacal Time may not even make sense for many application,
e.g. What is the "Local Time" of a global Land Use Raster?

Hence the general recommendation for M2M communication is to handle
time zones and time zone offsets explicitly.

-Matthias

Am Donnerstag, den 02.05.2019, 15:09 +0200 schrieb Falko Vincent
Partzsch:
> 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



_______________________________________________
GeoTools-GT2-Users mailing list
GeoTools-GT2-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

Reply via email to