rusackas opened a new pull request, #42589: URL: https://github.com/apache/superset/pull/42589
### SUMMARY This is a **test-only PR** opened as a TDD-style validation of issue #37925. #37925 (filed 2026-02) reports that datetime fields show inconsistent, non-uniform time shifts in Bar Charts and Scatter Plots versus the same data in SQL Lab, with per-row shifts that don't match a single fixed offset (e.g. +16h30m on one row, +10h on another, +14h20m on a third). dosubot's investigation across several follow-up comments pinned the mechanism on `normalize_dttm_col` (`superset/utils/core.py`), specifically its handling of the dataset's UTC offset and time-shift, being applied inconsistently. That doesn't hold up once you read the function: `_col.offset` and `_col.time_shift` are each a single scalar value added to the whole column via a plain `timedelta(...)`/`parse_human_timedelta(...)`, applied uniformly to every row. There's no branch that varies the applied amount per row, so this function structurally cannot produce a shift that depends on that row's own value. The existing `test_normalize_dttm_col_with_offset` already confirms the offset is uniform across rows for date-only values; it just didn't cover the reporter's exact confirmed config (full timestamps at second-level precision, offset explicitly 0/"UTC", no time shift). Worth noting for whoever picks this up next: in the reporter's own three examples, each shift exactly equals that row's own time-of-day (16:30:00 → +16h30m, 10:00:00 → +10h, 14:20:00 → +14h20m). That's a much more specific, mechanistic pattern than "offset misapplied," and it isn't something `normalize_dttm_col`'s uniform-per-column arithmetic can produce. It points somewhere else in the pipeline, likely frontend axis/tooltip formatting, not this function. This PR adds one regression test on `normalize_dttm_col`: 1. **`test_normalize_dttm_col_second_precision_no_offset_matches_source`** — reproduces the reporter's confirmed config (offset=0, no time_shift, `%Y-%m-%d %H:%M:%S` grain, three distinct timestamps) and asserts the values pass through unchanged, locking in that this function is not the source of the reported bug. ### How to interpret CI - **CI green** (expected, confirmed locally) → `normalize_dttm_col` is not the mechanism behind #37925's reported bug. The underlying issue may still be real, but the root cause is elsewhere; this PR alone doesn't close it. I'm marking `Closes #37925` off given that ambiguity, happy to be told otherwise. - **CI red** → would mean something changed since local verification; treat as a real regression in this function specifically. ### TESTING INSTRUCTIONS ```bash pytest tests/unit_tests/utils/test_core.py -k normalize_dttm_col -v ``` Ran locally against Python 3.11 (repo's local `pytest.ini` config, `--noconftest` not needed once run directly): 14 passed, including the new test. ### ADDITIONAL INFORMATION - [ ] Has associated issue: relates to #37925 (does not close it, see above) - [ ] Required feature flags: - [ ] Changes UI - [ ] Includes DB Migration - [ ] 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]
