Potentially Wrong Expected Output for ExpandPerHour

[cmoesel]

The test CqlIntervalOperatorsTest.Expand.ExpandPerHour specifies the following CQL:

expand { Interval[@T10:00, @T12:30] } per hour

and expected result { Interval[@T10:00, @T11:00), Interval[@T11:00, @T12:00) }.

The CQL specification, however, says:

If the interval boundaries are more precise than the per quantity, the more precise values will be truncated to the precision specified by the per quantity. In these cases, the resulting list of intervals may be more broad than the input range due to this truncation.

It then uses the same exact CQL from the test case above as an example and indicates that the correct answer should be { Interval[@T10, @T10], Interval[@T11, @T11], Interval[@T12, @T12] }.

To be honest, however, I'm not sure if the example is correct since it truncated the inputs by removing minutes precision rather than setting minutes to 0. The spec does not indicate how dates should be truncated (except by example here) -- but it's notable that Interval[@T10, @T10] does not really represent the whole 10 o'clock hour since @T10 is typically interpreted as some time during the 10 o'clock hour.

[raleigh-g-thompson]

The spec seems to be clear on how to handle the interval expansion
`The per argument determines the size of the resulting intervals and must be a quantity-valued expression compatible with the interval point type. For numeric intervals, this means a quantity with the default unit '1' (not to be confused with the quantity value, which may be any valid positive decimal). For Date-, DateTime-, and Time-valued intervals, this means a quantity with a temporal unit (e.g., 'year', 'month', etc).

Conceptually, the per argument to the expand operator partitions the value-space for the operation into units of size 'per', and the intervals will be expanded aligning with those partitions. Note that the 'per' partitions start from the starting boundary of the first input interval, ordered.`

@brynrhodes Can you provide clarification?

[cmoesel]

Yes, I agree that the description you've pointed to seems clear. But I think that the part I quoted, along with the example, muddies it. That's where we really need clarification. In particular, should @T10:00 really be truncated to @T10 (as in the example, which introduces imprecision) or should it stay @T10:00?

And since the statement that "the resulting list of intervals may be more broad than the input range due to this truncation" can be confusing, it's probably worth including an example there too. Is this what it's trying to get at:

expand { Interval[@T10:30, @T12:00] } per hour

results in

{ Interval[@T10:00, @T11:00), Interval[@T11:00, @T12:00) }

if truncation is done by zeroing out time components? Maybe it is, but that still feels strange, especially considering the previous bit that says:

Note that the 'per' partitions start from the starting boundary of the first input interval, ordered.