Collection: Open intervals for temporal extents

[m-mohr]

We recently took over a new clarification for the extents in collections from OGC APIs, see #1064.
While implementing this for stac-migrate, I realized that we may have to change some things here.

The spec says for temporal intervals:

Open date ranges are supported by setting either the start or the end time to null.

My understanding is that this allows only one of them to be null, so [null, null] is not allowed.
With the chanegs in #1064 the case may come up.

For example, if you had the following in a Collectionbefore:
[[null, "1990-01-01T00:00:00Z"], ["2000-01-01T00:00:00Z", null]]

The result of generating the "union" to fulfill the requirement in #1064 would be:
[null, null]

So what should we do? I'm not sure how to proceed with the implementation in stac-migrate.
For now I'm generating invalid extents as follows, but that feels pretty weird:
[[null, null], [null, "1990-01-01T00:00:00Z"], ["2000-01-01T00:00:00Z", null]]

I'm aware that this is an edge-case and may never happen in reality, but it's a case that the migration tool for example should handle and I'm not sure what to implement. The JSON Schema supports both elements being set to null, but removing the constraint from above make the requirement to set a temporal extent in Collections useless.

cc @cportele

[cportele]

Just to confirm that in OGC API Features [[null, null]] is valid. It is basically the temporal equivalent to a spatial extent [[-180.0, -90.0, 180.0, 90.0]] (which I think is valid in STAC).

Yes, a more specific extent will be useful for clients and for most datasets it should be possible to at least identify a start of the temporal extent. However, maybe there are cases where this is expensive to determine / keep up-to-date.

There is also a difference between a temporal: [[null, null]] or no temporal member for the API. The presence of a temporal extent indicates to clients that the items are temporal and can be queried in a meaningful way using the datetime query parameter. If there is no temporal member clients will assume that a datetime parameter has no effect.

[m-mohr]

Thanks, @cportele. So we require temporal and spatial extents in STAC and have the wording above, but we may just slightly change to allow open intervals in both directions.