Improved handling temporal extents

[soxofaan]

background story references: Open-EO/openeo-geopyspark-driver#34, Open-EO/openeo-processes#331, Open-EO/openeo-processes#394

Regarding temporal extents, there is a bit of (long standing) conflict between the current VITO back-end implementation (end timestamp is inclusive) and the official openEO spec (end timestamp exclusive).
The VITO back-end will at some point probably fix this by adapting the spec way, but this could potentially break some existing use cases, examples/demos, etc..

For example, a common usage pattern in the wild for (VITO) users and use cases: user knows that there is an observation on certain day, e.g. "2022-01-02", and specifies temporal extent like ["2022-01-02", "2022-01-02"]. This is strictly per-spec an empty interval and with Open-EO/openeo-processes#394 even invalid (throw error).

We should think of some ways to catch these problems at the level of the python client, e.g.

• warn when client detects that start==end
• fix the end date in some way (e.g. add 24 hours or something)
• allow the user to specify a single date string, e.g. "2022-01-02", and expand that under the hood automatically to the valid corresponding extent ["2022-01-02", "2022-01-03"]
• ...

[jdries]

@soxofaan @JohanKJSchreurs isn't this a duplicate of something that we fixed?

[soxofaan]

allow the user to specify a single date string, e.g. "2022-01-02", and expand that under the hood automatically to the valid corresponding extent ["2022-01-02", "2022-01-03"]

this was indeed implemented under #421/#468

[soxofaan]

Warning about and/or autofixing a temporal extent with identical dates like ["2022-01-02", "2022-01-02"] could still be considered as an extra feature, but I'm not sure if that is still worth it

[jdries]

let's not do the warning for now