Repository navigation
Honour the time-precision extension on dateTime, time and Period boundaries - #135
Merged
Merged
Conversation
…daries FHIR dateTime and time require minutes and seconds once an hour is present, while CQL allows hour- and minute-precision values. An engine that emits valid FHIR zero-pads the missing components and declares the real precision with the time-precision extension (http://hl7.org/fhir/StructureDefinition/time-precision) on the primitive element. The extractors now drop the padded components again, so `2005-05-10T10:00:00Z` declared at `h` is read as `@2005-05-10T10Z` and compares against the `@2005-05-10T10` style expectations in cql-tests. Values without the extension, with an unknown code, or without a time-of-day are unchanged, as is any timezone offset. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HrgCec45seYogQkmqRpSUi
alexzautke
marked this pull request as ready for review
September 17, 2026 17:53
bryantaustin13
added a commit
that referenced
this pull request
Sep 22, 2026
Resolves the conflict in datetime-interval-extractor.ts, which arose because this branch predates #129 and #135 and carried an older copy of the whole file. Taking either side alone would have lost work: - main's side drops this branch's null guards and its `highClosed: high !== null`, leaving an absent Period boundary reported as closed. - this branch's side drops #135's applyDeclaredTimePrecision on the `_start`/`_end` companion elements and #129's List<...> unwrapping in declaredPointType, which would have reverted time-precision support and lists of temporal intervals. The resolution keeps all of it: this branch's early-return guards and derived highClosed, wrapping main's precision-aware boundary extraction, with #129's List unwrapping untouched above. Verified after resolution: 247 tests pass, and each behaviour checked directly — a Period with hour time-precision extracts as @T10/@t12, List<Interval<System.Date>> still resolves to Date literals, an absent end yields highClosed:false, and null valuePeriod / valueRange / boundary no longer throw. tsc reports only the two pre-existing rest-routes.ts errors present on main. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Oct 1, 2026
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
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.
Why
FHIR
dateTimeandtimerequire minutes and seconds once an hour is present, but CQL allows hour- and minute-precision values (@2005-05-10T10,@T10). An engine that returns valid FHIR from$cqltherefore has to zero-pad the missing components, and the FHIR extensions pack providestime-precision(trial-use, value set of UCUM time-duration codes) to declare the real precision on the primitive element (_valueDateTime,_valueTime,_start,_end).Firely Server (via the Firely CQL SDK) emits exactly that, and today the runner reads
2005-05-10T10:00:00Z+time-precision = has@2005-05-10T10:00:00Z, so every hour- or minute-precision result fails against expectations such as@2005-05-10T10or{ @T10, @T11, @T12 }. TheDateTimeExtractoralready carried a TODO for this.What
value-type-extractor-utils.ts:declaredTimePrecision(element)reads the extension from a primitive's companion element;applyDeclaredTimePrecision(value, element)drops the components padded beyond the declared precision (h→hh,min→hh:mm,s→hh:mm:ss,ms→ unchanged). Values without the extension, with a code outsideh/min/s/ms, or without a time-of-day are returned unchanged, and any timezone offset is kept as sent. Nothing changes for engines that do not send the extension.DateTimeExtractor,TimeExtractorandDateTimeIntervalExtractorapply it tovalueDateTime/_valueDateTime,valueTime/_valueTimeandvaluePeriod.start|end/_start|_end.Interval<System.Time>), and a README paragraph next to the existingquantity-precisionnote.Effect on cql-tests against a conformant engine
CqlIntervalOperatorsTest / Expand / ExpandPerHour*(4 cases) go from fail to pass:@T10:00:00is now read as@T10.DateTimecases (DateTimeAdd5Hours,DateTimeHour,ToDateTime2, …) now extract as@2005-05-10T10Zinstead of@2005-05-10T10:00:00Z. They still differ from the offset-less expectations, which is the separate timezone-offset-policy topic tracked in Functionality to support testing of Time zone offset #119 and Wrong Expected Outcome for ToString of DateTime with No Offset Specified cql-tests#73 / Test Runner Not Detecting Equal Concept Values #81; this PR is orthogonal to that work and does not touch offsets.Verification
npx vitest run test/: 235 passed (224 before).tsc --noEmitclean. Prettier clean on the touchedsrc/andtest/files (README.md already failsprettier --checkonmain, unchanged here).🤖 Generated with Claude Code
https://claude.ai/code/session_01HrgCec45seYogQkmqRpSUi
Generated by Claude Code