Equate the Z and +00:00 spellings of UTC when comparing temporal lite… - #132
Open
bryantaustin13 wants to merge 1 commit into
Open
bryantaustin13 wants to merge 1 commit into
bryantaustin13 wants to merge 1 commit into
Conversation
…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.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Member
|
Thanks. You can resolve #83 when this gets merged. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…rals
ISO 8601 allows UTC to be written either as
Zor 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:00is left unequal to+00:00rather than guessed at.