cqframework / cqframework/cql-tests
Wrong Expected Outcome for ToString of DateTime with No Offset Specified
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 7
- Forks
- 8
- Avg merge
- 12d 5h
- Merged PRs (30d)
- 2
Description
The test CqlStringOperatorsTest.toString tests.DateTimeToString2 specifies the following CQL:
ToString(DateTime(2000, 1, 1, 15, 25, 25, 300))
and expected outcome '2000-01-01T15:25:25.300'.
When I run this through the TypeScript/JavaScript engine, I get the result 2000-01-01T15:25:25.300+00:00 because we run the tests using UTC-based evaluation request timestamps.
In the CQL specification, Constructing Date and Time Values says:
The only component that is ever defaulted is the timezone offset component. If no timezone offset component is supplied, the timezone offset component is defaulted to the timezone offset of the timestamp associated with the evaluation request.
This means that DateTime(2000, 1, 1, 15, 25, 25, 300) does have an offset, even if it was not supplied in the constructor. As such, I think it is reasonable (if not required) for the resulting string representation to also have an offset corresponding to the default offset.
Either the test should be updated so the input has an offset, or the test framework should declare what offset to run under, or the spec needs to be clarified about what's expected in this case.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with CqlStringOperatorsTest.xml lines 348-351 and run the DateTimeToString2 case under the UTC-based evaluation request timestamps described in the issue. Compare the result with the CQL specification's default-offset rule, then establish whether the test input, test framework's declared offset, or specification wording should change; done means the expected behavior is explicit and the test agrees with it.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, typescript
- Domain
- testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100