PDGGK commented on PR #17180: URL: https://github.com/apache/iotdb/pull/17180#issuecomment-5156108975
@henjoe — following up with a more useful answer than the one I gave in June. **Not merged.** As of master `75eaa40` (2026-07-31) the syntax still isn't there: `timeRange` in `IoTDBSqlParser.g4:1018-1021` has exactly two alternatives, `[start, end)` and `(start, end]`. `[start, end]` doesn't parse. Issue #17108 is still open and untriaged. **You probably don't need to wait, though.** If the goal is to make sure the final timestamp lands in a bucket, the existing left-closed form already does it for integer timestamps: `GROUP BY ([start, end+1), interval)`. For example `GROUP BY ([0, 101), 10ms)` includes `t=100`, and the Time column stays left-aligned the way you'd expect. One caveat if you go looking at the other existing form: `(start, end]` also includes the right endpoint, but it is *not* a drop-in replacement, because right-closed windows are reported by their **max** timestamp rather than their min (`ITimeRangeIterator.currentOutputTime()` — "minTime if leftCloseRightOpen, else maxTime"). The repo's own test shows it: `group by((0, 9], 2ms)` returns timestamps `2, 4, 6, 8, 9`, not `0, 2, 4, 6, 8`. So `[start, end+1)` is the closer substitute. **On the PR**, rather than leaving you waiting on it: it's 642 commits behind master, real CI has never run on the current head (only the greeting check), and — correcting what I wrote in June — `TimeRangeIteratorTest` does not actually cover the new syntax; every call site there passes the new flag as `false`, so `[start, end]` has no test at all. That same comment also said `ExpressionFactory` normalizes `[start, end]` to `[start, end+1)`; that's only true of the pushed-down predicate. The window iterator keeps the un-bumped end time and widens the final window instead, which is a semantic choice nobody has reviewed. So before asking anyone to spend time on it I'm going to rebase, add an integration test in the style of `IoTDBLeftORightCIT`, and put the design question on `dev@`: given that both `(start, end]` and `[start, end+1)` already exist, is `[start, end]` wanted as sugar, and if so should the last window widen or should an extra window be emitted. Either way you'll get a definite answer instead of an open PR — thanks for pushing on it. --- -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
