[Bug] Support inclusive end time syntax ] in GROUP BY clause IoTDB 2.0.5
- Langage dominant
- Java
- Étoiles
- 6.4k
- Forks
- 1.2k
- Merge moyen
- 1 j 23 h
- PR mergées (30 j)
- 115
Description
### Search before asking
- [x] I searched in the [issues](https://github.com/apache/iotdb/issues) and found nothing similar.
### Version
OS: Ubuntu 24.04 LTS
IoTDB: 2.0.5
### Describe the bug and provide the minimal reproduce step
Currently, the `GROUP BY` clause in IoTDB strictly uses the left-closed, right-open `[start, end)` time interval format. Users often need to include the data point exactly at the end time (e.g., `[start, end])`, but the current syntax does not support using `]` to specify an inclusive end time.
When querying time-series data, it is common to want a precise inclusive range (e.g., from `12:00` to `13:00` inclusive). To achieve this now, users must manually extend the end_time by a small fraction (e.g., `+1ms`) or by a full time interval unit, which is unintuitive and can lead to errors or off-by-one queries.
### What did you expect to see?
Support the standard interval syntax `]` to denote an inclusive end time in the `GROUP BY` clause.
Example:
Allow this syntax:
```SQL
SELECT count(s1) FROM root.sg.d1
GROUP BY ([2026-01-27T12:00:00, 2026-01-27T13:00:00], 1m)
```
### What did you see instead?
Current syntex doesn't allow `]` for end time. I have to use the below syntex:
```SQL
SELECT count(s1) FROM root.sg.d1
GROUP BY ([2026-01-27T12:00:00, 2026-01-27T13:00:00), 1m)
```
but it excludes the value at 13:00:00
### Anything else?
Current Workaround:
Users currently have to modify the timestamp manually:
```SQL
-- Extended by 1ms to capture the last point
GROUP BY ([2026-01-27T12:00:00, 2026-01-27T13:00:00.001), 1m)
```
### Are you willing to submit a PR?
- [ ] I'm willing to submit a PR!
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
Commencez par localiser le point d’entrée de la clause SQL GROUP BY et le traitement des bornes de fin des intervalles. Reproduisez les exemples de l’issue, puis vérifiez qu’un ] fermant est accepté et que les données exactement à l’horodatage de fin sont incluses sans modifier le comportement existant de [start, end).
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- java, sql
- Domaine
- databases
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- À l'abandon
- Clarté
- Plutôt claire
- Accessibilité débutants
- 45/100