Open soxofaan opened 3 months ago
A naive fix is flipping the default of exclude_max
to true, but this is of course a breaking change.
This is an experimental process, but we have indication that it is already being used. For example it is being used in https://github.com/Open-EO/openeo-community-examples/blob/main/python/ParcelDelineation/Parcel%20delineation.ipynb
It's indeed used by 2 or 3 users, but my feeling is that they are not necessarily affected, so I would consider to just fix it.
This is aligned with the between
process, which is also defaulting to inclusive bounds and has the same signature, including the exclude_max parameter.
Does this really need a fix? It can be changed at any time through the parameter.
another option:
leave as-is:
date_between(string x, string min, string max, ?boolean exclude_max = false) : boolean|null
but add
date_within(string x, temporal-interval:array<string|null> extent): boolean|null
Where the interval is handled left-closed (per definition of the temporal-interval
subtype), as in all the other places (load_collection
, filter_temporal
, load_stac
).
Counter-argument is that this might be confusing, but it should be straightforward to catch/report issues client side as date_between
requires at least 3 arguments while date_within
requires exactly 2 arguments
This confusion came up in a discussion with @VictorVerhaert:
date_between
handles the temporal extent as left+right closed by default:This is not in line with the left-closed definition of the temporal extents in
filter_temporal
,load_collection
,load_stac
, ...