Type operators testing error breakdown (CqlTypeOperatorsTest)

[bryantaustin13]

CqlTypeOperatorsTest fails commentary:

1. "passCount": 26,
   "skipCount": 0,
   "failCount": 9,
   "errorCount": 0

2. failing tests:
   AsQuantity (actual => EvaluationError:Library expression-1.0.0 loaded, but had errors: An operand identifier reference is hiding another identifier of the same name., An operand identifier reference is hiding another identifier of the same name., An operand identifier reference is hiding another identifier of the same name., Expression of type 'System.Quantity' cannot be cast as a value of type 'Quantity'.)
   ****** This is probably a test error. If we change 45.5 'g' as Quantity to 45.5 'g' as System.Quantity it passes. If we just use Quantity, that is a FHIR.Quantity. 5.5 'g' is a System.Quantity. If we are actually intending to do a FHIR.Quantity, then this is an engine error.

   CastAsQuantity (actual => EvaluationError:Library expression-1.0.0 loaded, but had errors: An operand identifier reference is hiding another identifier of the same name., An operand identifier reference is hiding another identifier of the same name., An operand identifier reference is hiding another identifier of the same name., Expression of type 'System.Quantity' cannot be cast as a value of type 'Quantity'.)
   ****** This is probably a test error. If we change 45.5 'g' as Quantity to cast 45.5 'g' as System.Quantity it passes. If we just use Quantity, that is a FHIR.Quantity. 5.5 'g' is a System.Quantity. If we are actually intending to do a FHIR.Quantity, then this is an engine error.

   CodeToConcept1 (actual has codes as an array and display(undefined) while expected just has codes with no display)
   ****** This is an engine error. The spec states "The ToConcept operator converts a value of type Code to a Concept value with the given Code as its primary and only Code. If the Code has a display value, the resulting Concept will have the same display value." In actual display is returned as 'undefined' and thus should not be returned.

   ToDateTime2 (actual is missing the time (@2014-01-01T) vs expected (@2014-01-01T12:05), which is correct)
   ****** This is an engine error. The spec states "The ToDateTime operator converts the value of its argument to a DateTime value. The operator expects the string to be formatted using the ISO-8601 date/time representation:
   YYYY-MM-DDThh:mm:ss.fff(+|-)hh:mm”

   ToDateTime3 (actual = @2014-01-01T12:05:05.955Z, not in expected)
   ****** This is an engine error. The spec states "If no timezone offset is specified, the timezone offset of the evaluation request timestamp is assumed.” The Z changes the value to “UTC offset = 0”.

   ToDateTime6 (actual = @2014-01-01T12:05:05.955Z expected = @2014-01-01T12:05:05.955+00:00)
   ****** These are actually semantically equal. Both Z and +00:00 mean the same thing. How should this be handled?
   The test ToDateTime(‘2014-01-01T12:05:05.955Z’) when sent to the API is returning this object
   {
   “resourceType”: “Parameters”,
   “parameter”: [
   {
   “name”: “return”,
   “valueDateTime”: “2014-01-01T12:05:05.955Z”
   }
   ]
   }
   the extraction from that:
   result.actual = resultExtractor.extract(responseBody)
   returns a string “2014-01-01T12:05:05.955Z”

These errors are the same
ToTime2 (actual => EvaluationError:Invalid precision index: 7)
ToTime3 (actual => EvaluationError:Invalid precision index: 7)
ToTime4 (actual === null vs "@t14:30:00.000
****** A timezone offset is in this test "ToTime('T14:30:00.0+05:30')"
https://cql.hl7.org/02-authorsguide.html#_date_date_time_and_time states
"Only DateTime values may specify a timezone offset, either as UTC (Z), or as a timezone offset. If no timezone offset is specified, the timezone offset of the evaluation request timestamp is used."
So either the test is wrong OR the engine should accept this and strip off the offset.