(superset) 01/01: test(utils): normalize_dttm_col with reported no-offset second-precision config (#37925)

[ru...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

rusackas pushed a commit to branch tdd/issue-37925-normalize-dttm-col-utc-offset
in repository https://gitbox.apache.org/repos/asf/superset.git

commit b71ac2e3f4af631099cfcf27539d6ee1e904dc1a
Author: Claude Code <no...@anthropic.com>
AuthorDate: Wed Jul 29 16:31:43 2026 -0700

    test(utils): normalize_dttm_col with reported no-offset second-precision config (#37925)
    
    #37925 reports datetime fields showing inconsistent, non-uniform time
    shifts in Bar/Scatter charts versus SQL Lab, with per-row shifts that
    don't match a single dataset-level offset. dosubot's investigation
    pinned the mechanism on normalize_dttm_col's offset/time_shift
    application being misapplied inconsistently.
    
    That doesn't hold up structurally: _col.offset/_col.time_shift are
    single values added via a plain timedelta to the whole column, which
    cannot produce a shift that varies per row based on that row's own
    value. The existing test_normalize_dttm_col_with_offset already
    confirms the offset applies uniformly across rows.
    
    This adds a regression test using the reporter's own confirmed
    config (offset=0/"UTC", no time_shift, second-level grain, multiple
    distinct timestamps) end to end, to make explicit that this function
    is not the mechanism the issue describes.
    
    Closes #37925
    
    Co-Authored-By: Claude Sonnet 5 <no...@anthropic.com>
---
 tests/unit_tests/utils/test_core.py | 40 +++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/tests/unit_tests/utils/test_core.py b/tests/unit_tests/utils/test_core.py
index 7fe3eee7eff..38aec8e0d3c 100644
--- a/tests/unit_tests/utils/test_core.py
+++ b/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,
+        ),
+    )
+
+    normalize_dttm_col(df, dttm_cols)
+
+    assert is_datetime64_dtype(df["dttm"])
+    assert df["dttm"].dt.strftime("%Y-%m-%d %H:%M:%S").tolist() == source_values
+
+
 def test_normalize_dttm_col_with_time_shift() -> None:
     """Test with time shift."""
     df = pd.DataFrame({"date_col": ["2020-01-01", "2021-01-01", "2022-01-01"]})