rusackas commented on code in PR #42589:
URL: https://github.com/apache/superset/pull/42589#discussion_r3679170840
##########
tests/unit_tests/utils/test_core.py:
##########
@@ -359,6 +359,46 @@ def test_normalize_dttm_col_with_offset() -> None:
assert df["date_col"][2].strftime("%Y-%m-%d %H:%M:%S") == "2022-01-01
03:00:00"
+def test_normalize_dttm_col_second_precision_no_offset_matches_source() ->
None:
+ """Regression test for #37925: second-precision timestamps with no
+ dataset offset configured ("UTC", i.e. offset=0) and no time shift must
+ pass through ``normalize_dttm_col`` unchanged and identically to their
+ source values, with no per-row drift.
+
+ The issue reports charts showing datetimes shifted by inconsistent,
+ non-uniform amounts versus the same data in SQL Lab, with the reporter's
+ own examples showing each shift exactly equal to that row's own
+ time-of-day (e.g. 16:30:00 shifted by +16h30m, 10:00:00 by +10h,
+ 14:20:00 by +14h20m). ``normalize_dttm_col`` applies a single
+ ``_col.offset``/``_col.time_shift`` uniformly via ``timedelta(...)`` to
+ the whole column (see ``test_normalize_dttm_col_with_offset`` above,
+ already green), which cannot structurally produce a shift that varies
+ per row based on that row's own value, so this function is not the
+ mechanism the issue describes. This test locks in the specific
+ reported config (offset=0, no time_shift, second-level grain, multiple
+ distinct timestamps) end to end to make that explicit.
+ """
+ source_values = [
+ "2026-02-15 16:30:00",
+ "2026-02-15 10:00:00",
+ "2026-02-11 14:20:00",
+ ]
+ df = pd.DataFrame({"dttm": source_values})
+ dttm_cols = (
+ DateColumn(
+ col_label="dttm",
+ timestamp_format="%Y-%m-%d %H:%M:%S",
+ offset=0,
+ time_shift=None,
+ ),
+ )
Review Comment:
This is deliberately scoped to normalize_dttm_col in isolation, not the
chart path. The point is to rule the function out as the mechanism, per-row
variable shifts, which is what #37925 actually reports, can't come out of a
uniform timedelta applied to the whole column, and that holds regardless of how
DateColumn gets constructed upstream. An integration test through Viz.get_df()
is a different, bigger PR.
--
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]
