Meaning of date only in time

[m-mohr]

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]

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]

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]

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]

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

[cportele]

@pvretano, sure.

[m-mohr]

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]

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]

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.