FHIR Chat · Date/Time comparison vs equality · fhirpath

Stream: fhirpath

Topic: Date/Time comparison vs equality


view this post on Zulip Bryn Rhodes (Aug 26 2020 at 14:04):

@Grahame Grieve , starting a new thread for this test:

    <test name="testStringQuantityDayLiteralToQuantity" inputfile="patient-example.xml"><expression>'1 day'.toQuantity() = 1 'd'</expression><output type="boolean">true</output></test>

view this post on Zulip Bryn Rhodes (Aug 26 2020 at 14:05):

This one is actually highlighting an inconsistency in the spec, there is a tracker #28144 to address that, but since UCUM definite-duration quantities and calendar durations above seconds are uncomparable, the result should be empty.

view this post on Zulip Grahame Grieve (Aug 26 2020 at 19:37):

the issue is units, not math logic. {day} is a non-unit

view this post on Zulip Bryn Rhodes (Aug 27 2020 at 02:09):

Agree that {day} is a non-unit, this issue is different, specifically day and d are not comparable, so should return empty.

view this post on Zulip Grahame Grieve (Aug 27 2020 at 02:28):

how are they not comparable?

view this post on Zulip Bryn Rhodes (Sep 02 2020 at 18:38):

For the same reason that year and 'a' are not comparable, one is a calendar duration, the other is a definite-duration UCUM unit.

view this post on Zulip Grahame Grieve (Sep 02 2020 at 20:35):

I understand why year and a are not comparable. And month. But I don't understand why for periods of week or less

view this post on Zulip Bryn Rhodes (Sep 02 2020 at 20:38):

Because of the possibility of leap seconds, only seconds and below are technically exactly the same between the calendar and UCUM units.

view this post on Zulip Grahame Grieve (Sep 02 2020 at 20:47):

that's not exactly a real world issue.

view this post on Zulip Bryn Rhodes (Sep 02 2020 at 21:13):

That's fair, but that was the resolution. If the reference implementations behave differently, we can deal with that as an errata I think.

view this post on Zulip Bryn Rhodes (Sep 04 2020 at 16:32):

Added a comment to this effect to this tracker: https://jira.hl7.org/browse/FHIR-28144?filter=12608

view this post on Zulip Bryn Rhodes (Sep 04 2020 at 16:40):

And committed a change to the fhir-path-tests to address it. Specifically:

'1 day'.toQuantity() = 1 'd' // true
'1 \'wk\''.toQuantity() = 1 week // true
'1 \'mo\''.toQuantity() = 1 month // empty
'1 \'a\''.toQuantity() = 1 year // empty

view this post on Zulip Paul Lynch (Sep 30 2020 at 17:02):

Bryn Rhodes said:

And committed a change to the fhir-path-tests to address it. Specifically:

'1 day'.toQuantity() = 1 'd' // true
'1 \'wk\''.toQuantity() = 1 week // true
'1 \'mo\''.toQuantity() = 1 month // empty
'1 \'a\''.toQuantity() = 1 year // empty

@Bryn Rhodes - Your proposed resolution to J#28144 says "above days" should return empty, not "above weeks". (I am just objecting to apparent inconsistency, not to "weeks".)

view this post on Zulip Bryn Rhodes (Sep 30 2020 at 20:12):

Agreed, and when I applied this to CQL as part of alignment/reconciliation there, I noted weeks everywhere. See Equal for example.

view this post on Zulip Bryn Rhodes (Sep 30 2020 at 20:12):

I've added this as a note to the comment on that tracker.


Last updated: Apr 12 2022 at 19:14 UTC