SEPURI-SAI-KRISHNA opened a new pull request, #43204:
URL: https://github.com/apache/superset/pull/43204
<!-- PR TITLE: fix(chart): accept quarter and day in end-of time ranges -->
### SUMMARY
Every `"end of ... quarter"` and `"end of ... day"` time range raises a
`ValueError` instead of resolving to a date.
`handle_end_of()` declares five valid units and emits a `LASTDAY(...)`
expression for each of them:
```python
def handle_end_of(base_expression: str, unit: str) -> str:
valid_units = {"year", "quarter", "month", "week", "day"}
if unit in valid_units:
return f"LASTDAY({base_expression}, {unit})"
```
The `lastday` grammar rule that has to evaluate that expression only matched
three of them:
```python
Group(date_expr + comma + (YEAR | MONTH | WEEK) + ppOptional(comma))
```
So `quarter` and `day` are generated and then rejected by the very parser
they
are generated for. `DATEADD` and `DATETRUNC` in the same grammar already
accept
`YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND`, which is why
`"start of this quarter"` works while `"end of this quarter"` does not.
Reproducing on `master`:
```python
>>> from superset.utils.date_parser import get_since_until
>>> get_since_until(time_range="2020-01-01 : end of this quarter")
ValueError: Expected {'year' | 'month' | 'week'}, found 'quarter' (at char
27)
>>> get_since_until(time_range="2020-01-01 : end of this day")
ValueError: Expected {'year' | 'month' | 'week'}, found 'day' (at char 27)
```
The `time_range_lookup` pattern that routes these strings explicitly accepts
both units, so they are reachable from any free-form time range — the Explore
Advanced frame, a dashboard native filter's `default_time_range`, a
`TEMPORAL_RANGE` filter comparator, and `get_time_filter()` in Jinja:
```python
r"^(start of|beginning of|end of)\s{1,5}"
r"(this|last|next|prior)\s{1,5}"
r"([0-9]+)?\s{0,5}"
r"(day|week|month|quarter|year)s?$"
```
All affected forms: `end of this|last|next|prior [N] quarter(s)` and
`end of this|last|next|prior [N] day(s)`.
This PR adds `QUARTER` and `DAY` to the `lastday` rule and implements both in
`EvalLastDayFunc`. Quarter resolves to the last day of the quarter containing
the date; day resolves to that same day. Both are returned at midnight, which
is what every other unit here already does — `LASTDAY(..., month)` returns
the
final day at `00:00:00`, not at its end — so the convention is unchanged.
The quarter branch passes `month` and `day` to a single `replace()` call so
the
day is never briefly out of range for the new month (e.g. the 31st moving
into
a 30-day quarter-end month).
### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
N/A — backend-only fix.
### TESTING INSTRUCTIONS
```bash
pytest tests/unit_tests/utils/date_parser_tests.py
```
Four tests are added, all failing on `master` with the `ValueError` above:
| test | asserts |
| --- | --- |
| `test_lastday_supports_quarter_and_day` | the two units the grammar
rejected now evaluate |
| `test_lastday_quarter_boundaries` | all twelve months map to their
quarter's last day |
| `test_lastday_quarter_from_a_longer_month` | `2026-08-31` → `2026-09-30`,
and leap-year Q1 |
| `test_get_since_until_end_of_quarter_and_day` | end-to-end through
`get_since_until` |
Manually, in Explore → Time Range → Advanced, enter `end of this quarter` as
the END value. On `master` the "Actual time range" preview errors; with this
change it resolves to the last day of the current quarter.
### ADDITIONAL INFORMATION
- [ ] Has associated issue:
- [ ] Required feature flags:
- [ ] Changes UI
- [ ] Includes DB Migration (follow approval process in
[SIP-59](https://github.com/apache/superset/issues/13351))
- [ ] Migration is atomic, supports rollback & is backwards-compatible
- [ ] Confirm DB migration upgrade and downgrade tested
- [ ] Runtime estimates and downtime expectations provided
- [ ] Introduces new feature or API
- [ ] Removes existing feature or API
### CHECKLIST
- [ ] CI checks pass
- [x] Tests added/updated
- [ ] Documentation updated
- [x] PR title follows conventions
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
