Require nullable start_datetime and end_datetime columns?

[gadomski]

It's currently a bit of a PITA to correctly query datetimes from stac-geoparquet, because we don't know if start_datetime and end_datetime are in the schemas or not (e.g. here's some backflips in stac-rs). Would there being any downsides to requiring all three datetime columns (datetime, start_datetime, and end_datetime, each as nullable) in the stac-geoparquet spec, to take some load off of query implementers?

This would be a breaking change so would be part of a v2.0 of the spec.

[kylebarron]

I think requiring all three columns to exist would be a significant tradeoff. In particular, it's a big benefit to be able to statically know from your schema if only has one or the other set of columns.

While it's slightly annoying to have to check the schema for which columns are present, that's a check that can be made once and in the vast majority of times that solely one or the other are present in a collection, the runtime operation can be faster.

I'd argue it's much easier/faster at runtime to check once in the schema instead of every row. Because if all three must be present in the schema, you have no idea in advance if all of the rows actually just have a bare datetime value, which means you would never have to even check the start_datetime field