search

opengeospatial / ogcapi-records

An open standard for the discovery of geospatial resources on the Web.
https://ogcapi.ogc.org/records
Other
59 stars 28 forks source link

Meaning of date only in `time` #277

Closed m-mohr closed 11 months ago

m-mohr commented 1 year ago

Reading through http://docs.ogc.org/DRAFTS/20-004.html#sc_temporal_information I see that full-date (i.e. date only) is allowed as an alternative to date + time. It is not 100% clear what that means.

Is {date: "2020-01-01"} equivalent to {interval: "2020-01-01T00:00:00Z/2020-01-01T23:59:59Z"} or {interval: "2020-01-01T00:00:00Z/2020-01-01T24:00:00Z"}?

Is {interval: "2020-01-01/2020-01-02"} equivalent to {interval: "2020-01-01T00:00:00Z/2020-01-02T00:00:00Z"} or {interval: "2020-01-01T00:00:00Z/2020-01-02T23:59:59Z"} or ...?

pvretano commented 1 year ago

First comment is that this is a direct copy from JSON-FG. So if there is a problem here then we may need to clarify here and in JSON-FG.

Is {date: "2020-01-01"} equivalent to {interval: "2020-01-01T00:00:00Z/2020-01-01T23:59:59Z"} or {interval: "2020-01-01T00:00:00Z/2020-01-01T24:00:00Z"}?

I think the second one is wrong because T24 is not valid according to the BNF in RFC3339. I don't think the first one is equal to the reference date either since it is shy 1 second ... but that determination (I think) depends on the precision you are trying to achieve.

Is {interval: "2020-01-01/2020-01-02"} equivalent to {interval: "2020-01-01T00:00:00Z/2020-01-02T00:00:00Z"} or {interval: "2020-01-01T00:00:00Z/2020-01-02T23:59:59Z"} or ...?

If I am reading RFC3339 correctly then something like "2020-01-02" means a full 24 hour period and so the first internal is not equal to the reference interval since it is shy 23.99... hrs. The second is not equal either since it is shy 1 second but again precision comes into play here too I think.

@cportele, your thoughts?

m-mohr commented 1 year ago

Thanks. I'm aware that 24 as the hour is invalid in RFC3339, it's just to make visualize the end of the day more easily. Interpret it as 23:59:59.99999... ;-)

cportele commented 1 year ago

Is {date: "2020-01-01"} equivalent to {interval: "2020-01-01T00:00:00Z/2020-01-01T23:59:59Z"} or {interval: "2020-01-01T00:00:00Z/2020-01-01T24:00:00Z"}?

At least in JSON-FG the two are not equivalent. See https://docs.ogc.org/DRAFTS/21-045.html#_instants.

This is the same as in CQL2: https://docs.ogc.org/DRAFTS/21-065.html#scalar-data-types.

Is {interval: "2020-01-01/2020-01-02"} equivalent to {interval: "2020-01-01T00:00:00Z/2020-01-02T00:00:00Z"} or {interval: "2020-01-01T00:00:00Z/2020-01-02T23:59:59Z"} or ...?

Again, no, for the same reasons.

pvretano commented 1 year ago

@cportele .... hmm ... might need to copy some of that text over to Records if that is OK with you.

cportele commented 1 year ago

@pvretano, sure.

m-mohr commented 1 year ago

Okay, thanks. I see a risk in implementation. In search, the date only seems ambiguous so that an implementation sounds very complex to do. It covers a date independant of the timezone, so a temporal query such as 2020-01-01T00:00:00Z/2020-01-01T01:00:00Z would need to include data with the time set to 2019-12-31, right? Or not?

I'm confused by it and it's likely that others are, too.

pvretano commented 1 year ago

06-JUL-2023: @m-mohr is right ... comparing a date to and internal specified using time stamps can be tricky so we need to say something in the specification about that. @pvretano will review and propose some revised text.

pvretano commented 1 year ago

10-JUL-2023: In CQL2 timestamp and dates are different datatypes and so if you want to compare, for example, a date to an interval composed of time stamps then you need to cast the date to a timestamp ... although CQL2 does not describe how to do the cast. @pvretano needs to add similar language to records or reference the CQL2 discussion.