Issues with temporal data, including (open) ranges / periods

[m-mohr]

I have several issues with how temporal data is handled by WFS at the moment, which I'd like to draw your attention to and hopefully facilitate some fruitful discussion:

First issue: In several parts of the spec, e.g. OpenAPI spec and REQ_fc-time-response.adoc, it states that:

temporal information is either a date-time or a period string that adheres to RFC 3339.

Examples given are:

"2018-02-12T00:00:00Z/2018-03-18T12:31:12Z" or "2018-02-12T00:00:00Z/P1M6DT12H31M12S"

RFC3339 does not specify any of that. Those formats are specified in ISO8601.

Second issue: Open date ranges, e.g. 2018-02-12T00:00:00Z until now, are not possible throughout the spec, may it be for filtering or describing data. We have use cases where this is required as data updates very frequently and it is not really a solution to update the timestamps in the accommodating collection metadata every time. Also it seems useful to search for data that is just newer or older than a timestamp.

Third issue: The temporal filter is specified to be named time. I don't really like that, because it's not specified to be just a time, but a date and a time. That's counter-intuitive. I'd vote to call it datetime instead. This would also allow to have an extension, which would allow to just filter by time, e.g. give me all features that are available at 12:00 or between 09:00 and 12:00. There was a similar discussion on that topic by the STAC guys: radiantearth/stac-spec#130

Fourth issue: In several JSON schema and OpenAPI definitions a the format is set to dateTime, but both JSON Schema and OpenAPI propose that it should be date-time.

[m-mohr]

Regarding the first issue:

The introduction of RFC3339 explicetly mentions:

Date and time expressions indicate an instant in time. Description of time periods, or intervals, is not covered here.

The periods mentioned in the WFS spec are just mentioned in the Annex, the title is "ISO 8601 Collected ABNF". Not sure why the periods are in there, but for me it sounds strange to refer to / rely on something that was explicetly stated to be not covered in the main text of the RFC and is only mentioned in an Annex that tries to create an ABNF for another spec (ISO 8601).

[m-mohr]

Regarding the *second issue:

I think it could be an option to just allow omitting parts of the temporal extent.
For strings: "2018-02-12T00:00:00Z/"
For arrays: ["2018-02-12T00:00:00Z", null]

[rcoup]

Hmm, ISO8601 doesn't specify open-ended ranges, or how to do inclusive vs exclusive bounds... and the next release of the standard is still WIP: https://stackoverflow.com/a/48872488/2662

[m-mohr]

Thanks for commenting!
No, ISO8601 doesn't specify that (yet). Dublin Core took a try, but only specified it for dates: http://www.ukoln.ac.uk/metadata/dcmi/date-dccd-odrf/2005-08-13/
Nevertheless, it is useful for us to allow open date ranges, so it would be nice to come up with a solution. As pointed out with the other issues there are things to fix anyway. Would appreciate discussions on all these issues.

[rcoup]

Postgres’ ranges are extensive & feature-complete: https://www.postgresql.org/docs/10/static/rangetypes.html But null/infinity/inclusive/exclusive might be OTT for what we’re after here. _Personally_ `A <= t < B` (ie. A is inclusive and B is exclusive) is what our team has coalesced around for range specifies. Where `null` for A/B extends to infinity. eg. “August” is `2018-08-01, 2018-09-01`, regardless of whether the particular timestamps are passed at date/hour/minute/second/anything precision.

[cportele]

First issue:

RFC3339 does not specify any of that. Those formats are specified in ISO8601.

Good catch. The idea was to restrict date/timestamps to the profiles specified in RFC3339. We need to be more precise here.

Second issue:

I agree we need open ranges. In our implementation we use null values in the temporal extent for this, too. I need to do some research about a good approach for the time parameter. Any additional ideas welcome.

[cportele]

Third issue: I do not have a strong opinion on this one. datetime would be ok for me, too. Any other views on this?

[cportele]

Fourth Issue: Oops, thanks for pointing this out!