Stream: fhirpath
Topic: Date operations
Grahame Grieve (Apr 25 2019 at 22:25):
Found a FHIRPath problem....
Grahame Grieve (Apr 25 2019 at 22:26):
see https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Period.20datatypes: should this be valid:
<valuePeriod> <start value="2019-04-25T16:47:00Z"/> <end value="2019-04-25"/> </valuePeriod>
?
Grahame Grieve (Apr 25 2019 at 22:26):
at present, it is labelled as not valid because
Grahame Grieve (Apr 25 2019 at 22:26):
start.hasValue().not() or end.hasValue().not() or (start <= end)
Grahame Grieve (Apr 25 2019 at 22:26):
but in fact, according to the semantics, it should be
Grahame Grieve (Apr 25 2019 at 22:27):
[start.hasValue().not() or end.hasValue().not() or (start.lowEdge() <= end.highEdge())]
Grahame Grieve (Apr 25 2019 at 22:28):
except, of course, we do not have lowEdge() and highEdge() defined in FHIRPath...
Grahame Grieve (Apr 25 2019 at 22:28):
or whatever else we would call them
Richard Townley-O'Neill (Apr 26 2019 at 04:37):
That's a problem.
Paul Lynch (Apr 26 2019 at 16:32):
The problem seems to be caused by the change to FHIRPath to disallow comparisons of DateTimes at differing precisions. In an older version, start <= end would have truncated start to the date, so that start <= end would be true. In the current version (being balloted) start <= end would return empty. It might be worth revisiting that decision.
Adding lowEdge/highEdge solves the problem, but the negative thing about them is that I think they would only apply to time types.
Lloyd McKenzie (Apr 26 2019 at 16:48):
Wouldn't they also apply to ranges?
Paul Lynch (Apr 26 2019 at 16:53):
It looks like FHIRPath doesn't have a range type (though FHIR does).
Grahame Grieve (Apr 26 2019 at 20:12):
it also applies to decimals which have variable precision. To do the same with a decimal, you need either precision or low/high boundary properties, which we currently do not have either
Paul Lynch (Apr 26 2019 at 22:05):
You might run into the same problem with times that you do with decimals. The FHIRPath grammar allows an infinite number of decimal places on seconds (though support is only required at the millisecond level - 4.1.6).
Grahame Grieve (Apr 26 2019 at 22:09):
right but that's usually a side issue to the main one, which really matters in a way it doesn't with decimals.
Grahame Grieve (Apr 26 2019 at 22:09):
so I would like to define precision() and lowBoundary() and highBoundary() for date and decimal and use them in a revised FHIRPath constraint on period and range...
Bryn Rhodes (Apr 28 2019 at 17:26):
What do lowBoundary() and highBoundary() return?
Bryn Rhodes (Apr 28 2019 at 17:45):
Never mind, I see, yes, useful operators, but shouldn't it be start.highBoundary() <= end.lowBoundary()? Otherwise we would allow the interval from @2019-04-25T16:47:00Z to @2019-04-25T00:00:00Z
Michel Rutten (Apr 28 2019 at 21:25):
These comparisons are tricky to implement. Would it be possible to introduce higher level comparison methods/operators that incorporate the nullability and precision checks, to simplify expressions and coach implementers onto the happy path?
Grahame Grieve (Apr 28 2019 at 22:18):
well, you're trading there - higher level = more tricky to implement
Grahame Grieve (Apr 28 2019 at 22:21):
interval @2019-04-25T16:47:00Z to @2019-04-25T00:00:00Z - would not be allowed because boundaries are:
@2019-04-25T16:47:00Z = @2019-04-25T16:47:00.0000000Z to @2019-04-25T16:47:01.000000000Z
@2019-04-25T00:00:00Z = @2019-04-25T00:00:00.00000000Z to @2019-04-25T00:00:01.0000000000Z
so start.lowBoundary() <= end.highBoundary() is false
Grahame Grieve (Apr 28 2019 at 22:26):
looking at my own internal date type, I would define the following functions to support all the things I do with dates:
- date +/- duration = date
- date - date = duration
- date.lowBoundary()
- date.highBoundary()
- date.toUTC() / date.toLocal()
- date.precision() / date.asPrecision()
- date.toDay()
- date.overlaps(date)
- date.between(min, max : date) : boolean
- date.compare(date) / date.canCompare(date)
Brian Postlethwaite (Apr 28 2019 at 23:42):
These also then I troduce the timezones into the dates.
Michel Rutten (Apr 29 2019 at 09:00):
I meant moving complexity away from FHIR Path expression authors to FHIR path compiler (server/API) implementers.
Michel Rutten (Apr 29 2019 at 09:01):
i.e. like the proposed date.overlaps(date) method
Paul Lynch (Apr 29 2019 at 21:35):
I think highBoundary() should not be included in the date's internal range. In other words, a date should be (internally) the range
[ date.lowBoundary, date.highBoundary )
This means the test above should use < instead of <=:
start.lowBoundary() < end.highBoundary()
Otherwise, if start=@2019-04-25T00:00:01Z and end = @2019-04-25T00:00:00Z, then start.lowBoundary = end.highBoundary, which I don't think is desirable.
Bryn Rhodes (Apr 29 2019 at 21:55):
I'm having trouble grokking that, start can't be after end.
Paul Lynch (Apr 29 2019 at 22:30):
That is what I was trying to prevent by excluding "highBoundary" from the internal range of the date.
Bryn Rhodes (Apr 29 2019 at 22:36):
I see
Grahame Grieve (Apr 30 2019 at 07:16):
oh right. I did that so low() <= range < high(). and then I agree that it should be < not <-
nicola (RIO/SS) (Apr 30 2019 at 17:41):
What are real use cases for all this "temporal" stuff in fhirpath?
nicola (RIO/SS) (Apr 30 2019 at 17:42):
It's a rabbit hole :)
Grahame Grieve (May 02 2019 at 18:05):
I need to get the period invariant fixed
Bryn Rhodes (May 02 2019 at 18:09):
Are you planning on defining those in the FHIR FHIRPath appendix?
Grahame Grieve (May 02 2019 at 18:23):
I don't know. I think they belong in the core on FHIRPath, actually.
Bryn Rhodes (May 02 2019 at 18:27):
I agree they eventually belong there, but is there a timing question there?
Grahame Grieve (May 02 2019 at 18:27):
yes
Bryn Rhodes (May 02 2019 at 18:29):
So, I'm happy to put definitions for them in, need to prep the reconciliation/publication branch for this ballot cycle anyway. Shall I take a stab at putting them there (and mark them STU?)?
Paul Lynch (May 02 2019 at 18:31):
Will we have a chance to comment on them before they are published?
Bryn Rhodes (May 02 2019 at 18:32):
Absolutely, and I need a tracker to support adding them.
Grahame Grieve (May 02 2019 at 19:25):
Bryn Rhodes (May 04 2019 at 01:18):
Sorry, I forgot that I had already captured this as a ballot comment against FHIRPath :) GF#20149
Bryn Rhodes (Jun 08 2019 at 22:28):
So, the result of lowBoundary() and highBoundary() is clear enough, but what is the result of precision()? Is it an integer returning the number of digits?
Bryn Rhodes (Jun 08 2019 at 22:28):
For decimals that's clear enough, but for Date/DateTime/Time, what is the result of (@2014).precision() for example. 4?
Last updated: Apr 12 2022 at 19:14 UTC
