Ujjwaljain16 opened a new pull request, #44237:
URL: https://github.com/apache/superset/pull/44237

   ### SUMMARY
   Native Time Range filters currently display evaluated ranges using raw 
ISO-style values (e.g. `2019-01-14`), with no way to configure how they're 
shown. Chart-level `Timestamp Format` does not flow into native-filter 
rendering — a native filter is not owned by any single chart, so inheriting one 
chart's format isn't architecturally sound.
   
   This adds an optional, filter-level **Display format** setting to the Time 
filter's Filter Settings tab. It reuses the existing D3 time-format 
infrastructure (`D3_TIME_FORMAT_OPTIONS` / `getTimeFormatter`) that already 
powers chart-level `Timestamp Format` controls (e.g. the Table viz's 
`table_timestamp_format`) — no new formatting system is introduced.
   
   Design notes:
   - When unset (the default for every existing filter), display behavior is 
byte-for-byte identical to today.
   - The format only affects the *evaluated* range shown in the pill/tooltip 
(e.g. for Custom/Advanced frames). Human-readable expressions such as `Last 
week` or `previous calendar month` are never passed through the formatter.
   - `time_range` serialization, query semantics, and the `DAYJS_FORMAT`-based 
`CustomFrame` datetime picker are untouched — this is a presentation-only 
change.
   - UTC handling is explicit: the backend returns naive ISO datetime strings, 
which are parsed with `extendedDayjs.utc()` (not local-time parsing) before 
formatting, so the formatted output preserves the original wall-clock digits 
regardless of the browser's timezone.
   
   Fixes #33724
   
   ### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
   _Not included in this PR — happy to add one if a reviewer would like to see 
the new "Display format" field in the Filter Settings tab._
   
   ### TESTING INSTRUCTIONS
   1. Create or edit a dashboard native filter of type **Time range**.
   2. In the Filter Settings tab, set **Display format** to e.g. `%d-%m-%Y 
%H:%M:%S`.
   3. Choose a **Custom** or **Advanced** time range and Apply.
   4. Confirm the filter pill on the dashboard now shows the range in the 
configured format, while a **Common**/**Calendar**/**Current** selection (e.g. 
"Last week") still shows the human-readable label, with the formatted range 
only in its tooltip.
   5. Leave **Display format** unset on an existing filter and confirm the 
display is unchanged from current behavior.
   
   Automated coverage:
   - 
`superset-frontend/packages/superset-ui-core/test/time-comparison/fetchTimeRange.test.ts`
 — custom format applied to both range endpoints, `-∞`/`∞` placeholders 
preserved, human-readable values left untouched, end-to-end `fetchTimeRange()` 
with a format, and a UTC-safety regression test (verified non-vacuous: 
reverting the UTC-safe parsing to local-time parsing makes this test fail with 
a reproducible timezone-shifted value under the suite's fixed 
`America/New_York` test timezone).
   - 
`superset-frontend/src/explore/components/controls/DateFilterControl/tests/DateFilterLabel.test.tsx`
 — the configured format reaches the evaluated-range tooltip while the 
human-readable pill stays untouched.
   
   ```
   npm test -- 
packages/superset-ui-core/test/time-comparison/fetchTimeRange.test.ts 
src/explore/components/controls/DateFilterControl/tests/DateFilterLabel.test.tsx
   npm test -- 
src/dashboard/components/nativeFilters/FiltersConfigModal/FiltersConfigForm/getControlItemsMap.test.tsx
 src/explore/components/controls/DateFilterControl/tests/
   ```
   All 83 tests pass. `npx oxlint`/`npx oxfmt` pass with no new warnings on the 
changed files. `npm run type` surfaces pre-existing `TS6305` "stale 
project-reference build output" errors across the whole repo (reproducible on 
unrelated files on a clean checkout without this change) — unrelated to this PR.
   
   ### ADDITIONAL INFORMATION
   - [x] Has associated issue: #33724
   - [ ] Required feature flags:
   - [x] 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
   - [x] Introduces new feature or API
   - [ ] Removes existing feature or API
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
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]

Reply via email to