Equate open and closed Time interval boundaries

[bryantaustin13]

Part of #85.

Problem

#110 made the comparator treat open and closed numeric interval boundaries as equivalent: [1.0, 4.0) equals [1.0, 3.99999999]. Time boundaries were left on the structural comparison, where the closed flags must match exactly. So an engine that answers with an open Time boundary fails against an expected closed one, even though both describe the same interval.

The two tests that conf/cql-execution-local.json still skips for #85 are this case. With their skips removed, cql-execution returns:

Test	Expected	cql-execution returns
ExceptTimeInterval	Interval[@T05:59:59.999, @T08:59:59.998]	Interval[@T05:59:59.999, @T08:59:59.999)
ExceptTime2	Interval[@T11:00:00.000, @T11:59:59.999]	Interval(@T10:59:59.999, @T11:59:59.999]

CQL 1.5.3 Predecessor (Successor is the same, with adding):

For Date, DateTime, and Time values, predecessor is equivalent to subtracting a time-unit quantity for the lowest specified precision of the value.

and End:

If the high boundary of the interval is open, this operator returns the predecessor of the high value of the interval.

So the end of [@T05:59:59.999, @T08:59:59.999) is @T08:59:59.998, and the two forms are the same interval.

Change

In boundariesEqual (src/shared/results-utils.ts), when exactly one of two Time-literal boundaries is open, the open one moves one unit of its own precision inwards before the values are compared:

• one hour for @T09
• one minute for @T09:00
• one second for @T09:00:00
• one millisecond for @T09:00:00.000

One fractional digit is still millisecond precision, so .1 is 100 ms.

Deliberately not equated:

• Boundaries at different precisions: @T08:59:59 is not treated as the closed form of @T09:00).
• A move that would leave the day: there is no Time before @T00:00:00.000 or after @T23:59:59.999.
• Date and DateTime boundaries: they keep the structural comparison. They would need calendar arithmetic and timezone offsets.

When both flags match, nothing changes.

Verification

• Unit tests: 242 pass, 7 new in test/results-utils.test.ts. They cover both reported cases, the step at each precision, wrong step sizes, mixed precisions, the day edges, unchanged same-flag behaviour, and Date boundaries staying structural.
• cql-execution (4.0.0-beta.1, cql-tests f591d9e, conf/cql-execution-local.json without its runner-issue skips): exactly ExceptTimeInterval and ExceptTime2 go from fail to pass. No other test changes.
• Java engine (HAPI FHIR 8.12.0 / clinical-reasoning 4.13.0 / CQL engine 5.4.0, cql-tests 9e92193, conf/localhost.json): 1641 pass / 182 fail / 19 skip / 0 error, the same as main, with no status or actual-value changes.
• Overlap with Compare DateTimes at the offset the evaluation actually ran at #145: this touches the same branch of boundariesEqual as Compare DateTimes at the offset the evaluation actually ran at #145. Applied on top of Compare DateTimes at the offset the evaluation actually ran at #145, the one conflicting hunk resolves by keeping this block and passing Compare DateTimes at the offset the evaluation actually ran at #145's options to the final resultsEqual. 277 unit tests then pass.

Follow-up

Once this merges, the two ExceptTime2 / ExceptTimeInterval skips can be removed from conf/cql-execution-local.json. They are the config's last skips for #85. Of the other tests the issue was raised for, IntegerIntervalExcept1to3 and Except12 already pass on main. DecimalIntervalExcept1to3 is now skipped there for a different reason (FHIR-59229, CQL 2.0 Decimal semantics).

🤖 Generated with Claude Code