Consider making end_datetime exclusive

[LiamBindle]

First off, thank you all for your hard work! We're using STAC with great success and it's been a terrific tool for organizing our data.

Next, sorry @m-mohr for missing your response and question in #1255. My bad and I see this has already gone ahead. I'm a bit concerned that #1280 introduces a logical flaw into the spec which is that it makes it impossible to represent a time series where every instant in time is covered by exactly one item. Feel free to close this if you don't think the topic needs any more discussion, but I just wanted to advocate for an exclusive end_datetime once more.

@m-mohr You raised this question in #1280:

Let's say I have a capture that takes two seconds: 2022-01-01T00:00:00Z - 2022-01-01T00:00:02Z (that's what I get from the source metdata).
How am I supposed to make this exclusive?

In this case, the end date in the source's metadata is already exclusive isn't it? The period [2022-01-01T00:00:00Z,2022-01-01T00:00:02Z) with an exclusive end date has a duration of exactly 2 seconds.

But what happens if there is another capture for the next 2 seconds of 2022-01-01T00:00:02Z - 2022-01-01T00:00:04Z? If the end date is inclusive then two items claim to cover the 2022-01-01T00:00:02Z instant in time whereas an exclusive end date handles it cleanly. If the end date is inclusive then you can't have a time series with exactly one item for every instant in time.

---

From #1280

[From @LiamBindle] Just wanted to voice my support for the end date being exclusive. I find it easier to work with intervals that have an exclusive end date because it means a collection of items can have complete temporal coverage without needing to tweak the end date by an undefined amount of time (e.g., a second or a microsecond).

[From @m-mohr] Isn't that an argument for having the end date inclusive? If it's exclusive and you create data (i.e. this is not the search use case), then you need to tweak the end date by an undefined amount of time.

I don't think so. Say you have an item that represents an average for the year 2018. When start is inclusive and end is exclusive you have start_datetime="2018-01-01T00:00:00.000000000Z" and end_datetime="2019-01-01T00:00:00.000000000Z". If the end date is inclusive then you need to subtract an undefined amount of time (1ns?) from the ending date. I.e., should it be end_datetime="2018-12-31T23:59:59.999999999Z"?

[m-mohr]

@LiamBindle If I get a start and end datetime for a capture, which should both be included in the range and the end_datetime is exclusive, I have the same issue. I just that I need to add an undefined amount of time instead of subtracting it.

I guess both cases are valid and we can always find use cases for both, but we should make the spec unambiguous so we have to choose one or the other and in any case someone will complain unless we add a property such as end_datetime_inclusive: true/false.

So not sure how to proceed with this issue. If you feel strongly about it, maybe start a discussion about it in one of the next STAC community calls where it potentially gets a bit more visibility than in this issue...

[LiamBindle]

Hey @m-mohr, thanks for the suggestion to raise it at the next community call. That makes sense so I'll try to attend the next one. Cheers!

[LiamBindle]

Sorry I wasn't able to attend the meeting yesterday, I was off because it was a holiday in Canada. I'll try to attend the next one

[LiamBindle]

Dang, apologies for missing the meeting. I forgot about it this morning. I'll try to attend the next one.

[emmanuelmathot]

[...] someone will complain unless we add a property such as end_datetime_inclusive: true/false.

So not sure how to proceed with this issue. If you feel strongly about it, maybe start a discussion about it in one of the next STAC community calls where it potentially gets a bit more visibility than in this issue...

I 👍🏼 on inclusive end_datetime convention (CoC principle)

[m-mohr]

Let's try to find other examples for standards that describe data (i.e. not filter expressions), e.g.

• ISO19915 etc
• Sentinel data and other satellites metadata
• ...

[m-mohr]

I did some research on standards / specifications that describe data (i.e. I excluded filtering because that's not our usecase here).

Inclusive:

• JSON FG (OGC superset of GeoJSON): https://docs.ogc.org/DRAFTS/21-045.html#_intervals
• OGC API - Features (and Records): Collection extent: End inclusive or exclusive opengeospatial/ogcapi-features#934
• Dublin Core: https://www.dublincore.org/specifications/dublin-core/dcmi-period/ ("maximally inclusive" 😅)
• DCAT: https://www.w3.org/TR/vocab-dcat-3/#basic-example (search for "closed interval")

Exclusive:

• Schema.org temporalCoverage: https://schema.org/temporalCoverage

Undefined:

• Schema.org endDate: https://schema.org/endDate
• ISO19115 (German translation): I did not find any information whether EX_TermporalExtent has an inclusive/exclusive end
• OWL Time: https://www.w3.org/TR/owl-time/ - not sure

It seems to lean towards inclusive ends, but I think I'd ultimately make it dependant on what OGC API - Features says.
We do not only need to define this for Items (start/end_datetime) but also for the temporal intervals in the Collection.
The handling of those two part should be aligned.

[m-mohr]

Due to opengeospatial/ogcapi-features#934 we'll inherit inclusive bounds for temporal extents in Collections. JSON FG is also inclusive, which OGC API - Records is based on and we try to align with Records as much as possible.
For me inclusive bounds as defined in #1280 have currently more evidence and backing than exclusive bounds. I'll keep this open for another week or so, so that other people can contribute additional evidence for exclusive or inclusive bounds though and then we can make a final decision in one of the next Community meetings.

[m-mohr]

We should probably also clarify that for the collection extent, see opengeospatial/ogcapi-features#934

[m-mohr]

Discussed in STAC community meeting: We think inclusive is the right choice based on the research I did above.