Time ranges and the "datetime" field

[m-mohr]

For time ranges we have the datetime-range extension. Unfortunately, it is not clear what to set for the required datetime field in a STAC Item. Should it be the first date-time? Should it be some kind of a middle value?

This issue appears often for the SAR extension/DAR data, videos and timeseries bundled in a single asset.

As I feel the datetime field is somewhat limited or not clearly specified for quite a good amount of data, I'd propose to make the datetime-range extension core and to require either a single datetime in the datetime field or a range with the start_datetime and end_datetime fields. Both could also be used together.

We can easily validate this using JSON schema (anyOf).

What do others think?

[matthewhanson]

There are some cases where all 3 dates are needed. For instance, you might have a range of datetimes for some data, but there is also a nominal date. MODIS product MCD43A4 is like this where it is a 16 day mosaic but the values have been corrected to represent the middle day in that range.

I think datetime should always be required, the ranges should be optional, and datetime should be the center time of nothing else.

[m-mohr]

That's why I wrote:

Both could also be used together.

Why always require a center time though?

[m-mohr]

We'll move datetime-range extension to core, remove the prefix.
datetime will still be required, datetime-range optional.
Extensions (e.g SAR, Video) that use datetime-range must say what datetime is (central, start, end, ...) (This is the todo here.)

[m-mohr]

It still feels that by requiring a single instance in time we are moving a server implementation issue to the spec. I've now seen this another time in the PR for Tiled Assets #614 that the datetime just doesn't seem properly used where a datetime range would be more applicable. And there are so many more use cases (timeseries, videos, mosaics, ...).

[m-mohr]

Recent discussions lead to the idea to allow null for datetime if start_datetime and end_datetime are specified.

[m-mohr]

Will probably be tackled by #792