Equate the Z and +00:00 spellings of UTC when comparing temporal lite…

[bryantaustin13]

…rals

ISO 8601 allows UTC to be written either as Z or as +00:00, and the two denote the same instant. A test declaring one spelling failed against an engine that returned the other, purely on notation.

ToDateTime('2014-01-01T12:05:05.955Z') is the case in the suite: the engine returns valueDateTime "2014-01-01T12:05:05.955Z", which the test declares as @2014-01-01T12:05:05.955+00:00. The value is right; only the offset is spelled differently.

Normalizing happens in the comparison rather than in the extractor, so the value is still reported exactly as the engine returned it — cql-test-results documents that actuals are never reformatted, and rewriting the extracted value would have changed what appears in the report.

The rule is deliberately narrow: both sides must be @-prefixed CQL temporal literals ending in a UTC designator. A genuine String result of "Z", or an unprefixed timestamp string, is never rewritten. A non-UTC offset is not treated as UTC, and -00:00 is left unequal to +00:00 rather than guessed at.

[cmoesel]

Thanks. You can resolve #83 when this gets merged.

[bryantaustin13]

Closing in favour of the DateTime comparison change for #138, which covers this case as part of a general rule. That change is #145, stacked on #142.

Rather than equating only the two spellings of UTC, it compares DateTimes as instants: two DateTimes are equal when, at the same precision, they denote the same instant. A side written without an offset is read at the offset the evaluation actually ran at. Z and +00:00 therefore compare equal, as they did here, and so does an offset-less expected value against an engine's …-06:00 result (#84).

Verified on the case this PR targeted: ToDateTime6 (@2014-01-01T12:05:05.955+00:00 expected, …Z returned) passes on that branch against CQL engine 5.3.0, along with 25 other DateTime tests, and no other result changes.

The utc-designator-equivalence branch is left in place for reference.