Stream: fhirpath
Topic: Equality with partial DateTimes
Paul Lynch (Mar 08 2019 at 21:41):
Did the rules around = and ~ for partial DateTime and Time change between http://hl7.org/fhirpath/ and http://hl7.org/fhirpath/2018Sep/, or was it simply clarified in the latter? Also, in the latter, there seem to be two contradictory statements (from 6.1.1. = (Equals)):
1) "For Date, DateTime and Time equality, the comparison is performed at the unit with the most precision of either input." (which suggests that comparison between two DateTimes of differing precision should be attempted)
2) "If the input values have different levels of precision, the result is empty ({ })." (which says the comparison between two DateTimes of differing precision should always result in empty).
Grahame Grieve (Mar 11 2019 at 10:57):
@Bryn Rhodes
Bryn Rhodes (Mar 13 2019 at 04:36):
The rules for equality were brought into alignment with what the various engines were doing. There was variability in the behaviors, and the spec wasn't as clear as it could have been, so we clarified in the 2018Sep ballot, and have since clarified further. If you look at the 2019May draft: https://github.com/FHIR/fluentpath/blob/master/spec/2019May/index.adoc#equality that's the clarified description (though there may still be some minor edits as I finish applying the trackers over the next few days).
Paul Lynch (Mar 15 2019 at 14:50):
Per the link provided by @Bryn Rhodes for the May version, the algorithm for determining equality would result in:
2012-01 = 2012 // empty 2012-01 = 2011 // false 2012-01 ~ 2012 // false
Questions:
1) Is that the desired behavior?
2) How is returning empty in the above case (instead of false due to the differing precision) useful?
Comment: It would be more efficient to return empty whenever the precision differed, and only otherwise proceed to checking equality, because only a single check for equality would be needed.
Bryn Rhodes (Mar 15 2019 at 14:59):
Because the first equality comparison is asking whether some day in the month of January of 2012 is equal to some day in the year 2012, and how can we know whether that's the case?
Paul Lynch (Mar 15 2019 at 15:00):
And what does 2012-01 ~ 2012 ask?
Bryn Rhodes (Mar 15 2019 at 15:01):
Where they are equivalent, in which case we don't care about the uncertainty.
Bryn Rhodes (Mar 15 2019 at 15:21):
Does that help?
Paul Lynch (Mar 15 2019 at 16:17):
Yes, although I am confused about the motivation for this behavior. It would be helpful if the spec could include some use cases to support it, because it is not the only behavior one could imagine. For instance, "2012-01-14 = 2012" could be asking the question "is there overlap between the two implied ranges of time" or "are they equal to the common precision". I am not saying that that functionality is needed, but I would have expected = or ~ to support that.
Bryn Rhodes (Mar 16 2019 at 00:45):
I can see using = for "are they equal to the common precision", but that's a less general operation and so would want to see a different operation that specifically did that (comparison to a specified precision). I have a hard time seeing = being a reasonable symbol to use to ask the question "is there overlap between the two implied ranges of time" though.
Richard Townley-O'Neill (Mar 18 2019 at 00:08):
The defined behaviour for = and ~ in dates makes sense to me.
It seems that some more date functions are needed; maybe
overlapDate(date,date):boolean - returns true when, after truncating the more precise date to be the same as the less precise date, the results are equal.
and
truncDate(date, precision):date
Paul Lynch (Mar 21 2019 at 14:39):
@Bryn Rhodes With the algorithm outlined in the May version, what is the result of:
@2018-02-03T22-04:00 = @2018-02-04T06:01+04:00
This is the same date time, expressed in different time zones, and at different precisions. I think the answer will clarify what "respecting timezone offsets" means in the phrase, "the comparison is performed by considering each precision in order, beginning with years (or hours for time values), and respecting timezone offsets". My first attempt to follow that resulted in a comparison of "2018" at -04:00 with "2018" at +04:00, which would be false, but I think the answer for the expression above is supposed to be "empty".
Bryn Rhodes (Mar 21 2019 at 14:50):
Right, for comparisons, if either or both of the inputs have a timezone offset, the values have to be converted to a common timezone offset prior to running the comparison, which would then result in empty because the values have differing precision.
Last updated: Apr 12 2022 at 19:14 UTC
