Hi list, I found what it may be a bug in the code that GeoServer uses to transform a reduced accuracy time query into a time range query when executing a WMS request with TIME dimension.
If so, it would be surely a minor issue since it deals with millisecond, but in certain application fields even milliseconds matter. I have a v.11 PostGIS DBMS with GeoServer v.2.15.2 running inside a Tomcat v.9.22 in a OpenJDK Java v.11. Time dimension is specified with two fields (start and end time) of timestamptz data type. When you specify, in a WMS query, a value for the TIME parameter that has a reduced accuracy (less than a millisecond), GeoServer sends a SQL query to the underlying DBMS transforming the specified time instant into a time range. The rule for calculating the range, is to use the specified value itself for the min value of the query interval and to add a unit of the maximum accuracy time expressed by the user’s value (i.e. a year, a month, a day, an hour…) minus a millisecond to find the maximum. That rule seems to be correctly applied until we specify fractions of second, that is when we limit the accuracy of the time value to tenths or to hundredths of second. This is what it happens (I omitted for the sake of clarity, the Zulu time zone notation for the input and consequent local time zone transformation in the SQL query): TIME = 2018-06-20T16:32 à max _time = 2018-06-20T16:32.59.999 (max accuracy = 1 minute, range CORRECT) TIME = 2018-06-20T16:32:45 à max _time = 2018-06-20T16:32:45.999 (max accuracy = 1 second, range CORRECT) TIME = 2018-06-20T16:32:45.*4* à max _time = 2018-06-20T16:32:45.*004 *(max accuracy = 1 tenth of second, range *WRONG*, should be 2018-06-20T16:32:45.409) min_time also wrong = max_time TIME = 2018-06-20T16:32:45.*27* à max _time = 2018-06-20T16:32:45.*027* (max accuracy = 1 hundredth of second, range *WRONG*, should be 2018-06-20T16:32:45.269) min_time also wrong = max_time TIME = 2018-06-20T16:32:45.271 à max _time = 2018-06-20T16:32:45. 271 (max accuracy = 1 millisecond, range CORRECT) When specifying a accuracy greater than a millisecond, the range transformation is yet WRONG, even if the documentation states that max accuracy supported is the millisecond, so this test case doesn’t make too much sense. However, I also reported it because it could be helpful for the debugging. TIME = 2018-06-20T16:32:45.*2716* à max _time = 2018-06-20T16:32:45.*716* (max accuracy = 1 tenth of millisecond, range WRONG, could be treated by truncating or approximating to millisecond) min_time also wrong = max_time Finally, even if the notation with one or two decimals (.4 or .27) was to be understood like .400 or .270, and not as a reduced accuracy notation, the transofrmation would still be erroneous . Stefano
_______________________________________________ Geoserver-users mailing list Please make sure you read the following two resources before posting to this list: - Earning your support instead of buying it, but Ian Turton: http://www.ianturton.com/talks/foss4g.html#/ - The GeoServer user list posting guidelines: http://geoserver.org/comm/userlist-guidelines.html If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
