In the conformance specification I have a test case for the check of C_TIME.range constraint over DV_TIME to validate time data.
In another thread I was arguing that there are some date/time/datetime expressions that are not strictly comparable, even though the current spec says otherwise. I have double checked semantics with ISO8601-1_2019 and this is a summary:
There is an open issue in the comparability of two date/time/datetime expressions with different precisions but shared values for the components they contain. For instance, in ISO 8601-1_2019, the expression
T23:20 is referring to a specific hour and minute, and
T23 is referring to a specific hour. Then, numerically, it’s not possible to say if
T23 < T23:20 or if
T23 > T23:20, though a string comparison could use some criteria to say if one expression is less than the other. But I think what is important is to compare what the expressions represent, not the syntax of the expressions (this is a huge difference IMO and why this problem seems extremely trivial to some or difficult to others).
That is because the expressions represent different time components, which are really intervals of time, and one interval contains the other (the 23rd hour of the day contains the minute 23:30).
Following that logic,
T23 is an interval/range of all the minutes and seconds in hour 23, where
T23:20 is an interval of all the seconds in minute 20 of the 23rd hour of the day. Graphically:
T23 = 23:00:00 [=============================================) 00:00:00 T23:20 = 23:20:00 [===) 23:21:00
[ marks the inclusion of the beginning
) marks the exclusion of the end
Though when the precisions are not the same but there are no shared components, then the expressions are comparable, for instance we can say
T22 < T2320, because all the minutes and seconds in the 22nd hour of the day come before the minute 23:20. Graphically:
T22 = 22:00:00 [=============================================) 23:00:00 T23:20 = 23:20:00 [===) 23:21:00
Similarly we can say
T22:45 < T23, since the whole minute 22:45 comes before all minutes and seconds in the 23rd hour of the day.
Then the question for C_TIME.range and this will get weird:
Besides nothing that reduced precision time expressions represent an interval or range when those reduced precision time expressions are used as limits for an openEHR Interval, then the result is the
union of both interval defined by the beginning of the lower limit and the end of the upper limit (this is my interpretation).
T11 represents the whole 11th hour of the day, from start to end, and
T22 represents the whole 22nd hour of the day from start to end, then
T11..T22 represents all hours, minutes and seconds from the start of hour 11 to the end of hour 22 (yes the end not the start!). Graphically:
T11 = 11:00:00 [====) 12:00:00 T22 = 22:00:00 [====) 23:00:00 T11..T22 = 11:00:00 [===============================================) 23:00:00
So something that might be counterintuitive in this notation is
T22:30 would be contained in the
T11..T22 interval, though it is not strictly comparable to
T22. In this case, since we are checking if a time expression is contained in an interval, this works because we are not really checking if one expression is less than the other, we are using the
contains operator instead of the
Then we can say
T22:30 is contained in
T11..T22 (interval), or even say
T22:30 is contained in
T22(since this is actually also an interval), but can’t say if
T22:30 < T22. It is important to understand we use two notations (Txx…Tyy and Tzz) that represent the same concept: an interval of time.
Again, all that is based on what the time expressions represent, not on the expression syntax itself.
I really don’t know if I’m being really stupid and can’t realize how things work or if I really discovered something worth discussing (or maybe a mix of both!).