Wrong Expected Output on Date Subtraction with Partial Dates

[cmoesel]

The test specifies the following CQL:

DateTime(2016,5) - 31535999 seconds = DateTime(2015, 5)

and expected outcome true.

This is tricky because the CQL spec says:

For partial date/time values where the time-valued quantity is more precise than the partial date/time, the operation is performed by converting the time-based quantity to the most precise value specified in the first argument (truncating any resulting decimal portion) and then subtracting it from the first argument.

It's not clear how to convert seconds into months. If we convert 31535999 seconds to months using UCUM units, we get 11.991786. If we then truncate the decimal portion (as the spec suggests) and subtract, we end up with DateTime(2015, 6), not DateTime(2015, 5). Translating seconds to days still comes in at 364.99999, which is less than a year, and therefore less than 12 months (landing on DateTime(2015, 6)).

So... although DateTime(2016,5) - 31535999 seconds is almost DateTime(2015, 5), it's not quite that. It would probably be best to either increase the seconds to 31557600 or fix the test to expect DateTime(2015,6). (Or tell me how engines should be doing this calculation to arrive at DateTime(2015, 5)).

[raleigh-g-thompson]

Agree with your analysis for the CQL spec and that the test is incorrect.

I'll fix the test.

[brynrhodes]

I think there's an opportunity for clarification in the spec here, in that it should indicate how the conversions are performed. We do say this in the FHIRPath spec:

https://hl7.org/fhirpath/#quantity-conversion-functions

So I'll propose that those conversion factors be added to the CQL specification, and that is then how the conversion from seconds to months should be performed.

https://cql.hl7.org/02-authorsguide.html#datetime-arithmetic

And we should be explicit that the conversions are applied in order of granularity, so that we get:

31535999 seconds / 60 = 525.599.9833 minutes
/ 60 = 8759.9997 hours
/ 24 = 364.9999 days
/ 30 = 12.16 months
/ 12 = 1.01 years

Which is different than what you would get if you went straight to years from days:

364.9999 days / 365 = 0.9999 years

So I think we need to be explicit about conversions for calendar units that they always go through each granularity (i.e. cannot skip granularities for conversion purposes).

[brynrhodes]

https://jira.hl7.org/browse/FHIR-53148

[cmoesel]

Ugh. Converting days to months using a conversion factor of 30 seems problematic, especially if you require that conversion from days to years should convert to months first (like in your example above). If we use that approach then doesn't that mean that 364 days < 1 year is false in CQL? I think that's a problem.

I noted that in the FHIRPath spec you link to, it actually says that the conversion factor for 1 year is "12 months or 365 days". This leaves some room for interpretation, and I would argue that if you have days, you should convert using the days conversion factor (instead of converting to months and then years).