Should Intervals and Sets support dates with times?

[JeroenDeDauw]

In the public spec, the examples of Intervals and Sets only show dates without time of day.

Should time of day be allowed in Intervals and Sets? Or is the highest precision "day"?

Example: 2021-04-24T16:00:00Z/2021-04-24T17:00:00Z

[JeroenDeDauw]

@mzeinstra @cnralux Maybe this question is answered in the proprietary spec?

Ping @GreenReaper

[GreenReaper]

It would be cool, but I suspect it's not in the spec, because if it was they would have had an example. Moreover, what they do say indicates it is excluded.

EDTF Level 0 adopts representations of a time interval where both the start and end are dates: start and end date only; that is, both start and duration, and duration and end, are excluded. Time of day is excluded.

Extended Interval (L1)

A null string may be used for the start or end date when it is unknown.
Double-dot (“..”) may be used when either the start or end date is not specified, either because there is none or for any other reason.
A modifier may appear at the end of the date to indicate "uncertain" and/or "approximate"

For Level 2 portions *of a date within an interval may be designated as approximate, uncertain, or unspecified.

Avoiding time makes it simpler for implementers. Perhaps we could call them Level 3 intervals? 😼

[GreenReaper]

As of the pre-submission draft (5.1.3 Interval) and the later ISO draft (clause 4 + appendix C), the intention was not to specify a time more precise than a day:

A [time] interval, as represented by a start date and an end date [(separated by a forward slash)], is a time interval beginning sometime during the start date and ending sometime during the end date. The actual instant[s] at which the time interval begins or ends can be narrowed down only to the precision of the start or end date. [..] Either endpoint may be a year, year-month, or year-month-day. The end endpoint must be later than or equal to the start endpoint.

[The last bit doesn't currently appear to be validated. Conversely, the library doesn't seem to allow cases where start and end are both one of open (..) or unknown ( ); in the ISO draft they are listed as allowed, but not recommended.]

[JeroenDeDauw]

Thanks for double checking.

In our case supporting dates with times is little or no extra work, so somewhat unfortunate it is not in the spec. That said, we implemented support for seasons in intervals on request from our client, which I now realize is also not in the spec. Rather unexpected you can't add any "single-value" EDTF date as interval start or end.

The last bit doesn't currently appear to be validated.

Indeed. Now tracked by #71. While looking at the set issue with many dates that you reported yesterday I found that sets likely should also have some more validation. Right now you can have [2000, 2000, 2000], [1000, ..2000] and [1000..2000, 1100..1900], all of which are rather dubious.

[GreenReaper]

From a personal perspective, I think it'd be useful to have a H-m-s+shift interval type representation.

However, I appreciate the main purpose is to implement EDTF as specified - and it's claimed that the text is a specified type in RDF, right?

Workarounds such as specifying separate start and end times as qualifiers exist - which would be readable by complaint EDTF implementations, and which I think could also be sorted on in SPARQL. (This would not replace the desire for intervals to act as a date in ProfessionalWiki/WikibaseEdtf#3 (comment).)

inukshuk/edtf.js/issues/12 describes a similar issue with seasons. They appear to be in the ISO draft under "4.7 Divisions of a year", but only at Level 1/2. Don't have access to the final specification.

[cnralux]

The ISO standard does not mention the use of [TIME] in any of the Level 1 or Level 2 features.
As [TIME] is only mentioned in level 0, I agree/assume that [TIME] is not part of EDTF for level 1 and level 2 features.

Furthermore, [TIME] adopts the complete representations for date and time of day on the extended format of the complete representation of a calendar date (--> sounds like [TIME] cannot be used as stand-alone).

And last but not least, the standard states that "Level 0 Time Interval" adopts representations of a time interval where both the start and end are dates (no durations and no times included).

[nigelgbanks]

In the private spec it is supported in section 10.2.a

10.2 Unknown or open start or end time intervals
...
a) Open end time interval
[intexpr]["/"]["."]

From the index:

intexpr a date and time expression accepted by the time interval representation as start or
end as determined in ISO 8601-1:2019, 5.4.3.

And from that document

5.4.3.a) Calendar date and local time of day
Basic format: [date][“T"][hour][min]
EXAMPLE 1 19850412T1015
Extended format: [dateX][“T”][hour][*:"][min]
EXAMPLE 2 1985-04-12T10:15