opensearch-project / opensearch-project/sql
[Feature] Span query in PPL should accept timezone parameter
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 176
- Forks
- 229
- Avg merge
- 2d 21h
- Merged PRs (30d)
- 43
Description
What is the bug?
The date histogram aggregation in query DSL has a timezone parameter, which convert the time value to the specified zone and then do the aggregation, but for now the span query in PPL doesn't have similar parameter, so the aggregation result may not meet the user's expectation.
For instance, in the Discover page of OSD, the timezone is local(read from the browser) by default, so when executing query DSL, the time_zone parameter is set explicitly in the date histogram aggregation, so the aggregation result is different from the result of PPL.
How can one reproduce the bug?
Steps to reproduce the behavior:
- Go to 'Discover' in OSD
- Execute DQL, see the histogram result
- Switch to PPL, check the histogram result
What is the expected behavior?
Span in PPL support the timezone parameter, then pass it to date histogram aggregation when converting to query DSL.
What is your host/environment?
OpenSearch 3.0
- Plugins
Do you have any screenshots?
If applicable, add screenshots to help explain your problem.
Do you have any additional context?
Add any other context about the problem.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the PPL span query path and compare it with the query DSL date histogram timezone parameter. Reproduce the mismatch in Discover using DQL and PPL, then verify that a timezone supplied to Span reaches the date histogram aggregation and aligns both histogram results.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, sql
- Domain
- backend-api-design, databases
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100