$filter operator do not support full ISO8601

[DanielBertocci]

According to the standard definition, in $filter operator the literal values SHALL be datetime values represented as ISO 8601 time string, as defined at https://docs.ogc.org/is/18-088/18-088.html#requirement-request-data-filter.

The following query performs correctly: {{url}}Observations?$filter=phenomenonTime ge 2022-01-01T00:00:00Z

But the followings produce an error and the datetimes are ISO8601 compliant: {{url}}Observations?$filter=phenomenonTime ge 2022-01-01T00:00:00+00:00 {{url}}Observations?$filter=phenomenonTime ge 2022-01-01T00:00:00+01:00

The error: { "code": 400, "type": "error", "message": "Query is not valid: \nEncountered an error at (or somewhere around) input:1:1" }

I am currently using the following docker image: fraunhoferiosb/frost-server-http:2.1.0-SNAPSHOT

I think that to be compliant to the standard, FROST Server should manage this situation.

[hylkevds]

Did you properly URL-encode the date? The + sign in a URL is the encoding for a blank space. So 2022-01-01T00:00:00+00:00 should be written as 2022-01-01T00:00:00%2B00:00 otherwise it is decoded to 2022-01-01T00:00:00 00:00

[DanielBertocci]

Thank you for your answer @hylkevds, I didn't think about URL encoding, I should have thought that before opening the issue. So I am glad that this use case is actually covered.

I wonder then if we can use my case to improve slightly the documentation on Example Queries mentioning to take care about URL encoding. I imagine we could give the opportunity to 'distracted' people like me to pay attention to that, maybe using the example I brought.

[hylkevds]

It's the second sentence in the first paragraph on that page :)

But I notice the bit about encoding is missing. That Strings are quoted with single-quotes ' and that quotes in strings are doubled. That geometries are geometry'<WKT String Here>' and durations duration'<ISO Duration String Here>'.

[DanielBertocci]

I have to confess I haven't noticed that part; what I meant was to provide the example and point the attention that is one of the few cases that create problems to URL encoding. I would say that a good place to put this information would be Filtering Entities and I would add:

• At the beginning:

URL Encoding:

It's important to note that all of the examples provided in this guide are not URL encoded for readability purposes. When using these examples in your queries, it is important to remember to properly URL encode the parameters, including spaces, quotes and geospatial data. Failure to do so may result in errors or unexpected results.

• Update the section with:

String functions

Use single quotes in strings. To escape single quotes in strings, use double single quotes ObservedProperties?$filter=name eq 'Temperature' Datastreams?$filter=name eq 'thing''s datastream'

• Update the selection with:

Temporal Functions

Use ISO8601 format without quotes Observations?$filter=phenomenonTime le 2022-01-01T00:00:00Z' Observations?$filter=phenomenonTime ge 2022-01-01T00:00:00+00:00' N.B. In the last example it is really important to urlencode, because + sign in a URL is the encoding for a blank space and brings to an unexpected result.

For durations use the following enconding: duration'' Observations?$filter=phenomenonTime gt now() sub duration'P1D'

• About geography, I think it is well documented already.

Thanks for your quick answers, I think we can close this issue.