[Bug] : Incorrect Datetime Conversion When Switching Display Formats in Bar Chart (Latest Master Branch)

[Alice-608]

Bug description

Describe the bug
When working with datetime columns in a Bar Chart (and potentially other chart types) in the latest master branch of Apache Superset, switching between different datetime display formats results in an incorrect Unix timestamp conversion, leading to a significant time discrepancy.

To Reproduce
Create a Bar Chart in Superset using a dataset containing a datetime column (e.g., 2026-02-15 16:30:00).
In the chart's configuration panel, switch the datetime display format between the available options.
Observe the resulting Unix timestamp value displayed after the format switch.

Expected behavior
The converted Unix timestamp should accurately represent the original datetime value. For the example 2026-02-15 16:30:00, the correct timestamp (in milliseconds) is 1771144200000.

Actual behavior
When switching formats, the resulting timestamp is 1771173000000. When converted back to a datetime, this corresponds to 2026-02-16 00:30:00, which is 8 hours later than the original datetime 2026-02-15 16:30:00. This indicates a critical error in the timezone handling or conversion logic when switching display formats.

Screenshots

Screenshots/recordings

No response

Superset version

master / latest-dev

Python version

3.9

Node version

16

Browser

Chrome

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot]

This is a known regression in the latest master branch: Bar Charts (and some other visualizations) can show incorrect and inconsistent datetime shifts due to how Superset applies dataset-level offsets and time shifts during backend normalization, which are not applied in SQL Lab. This normalization step can introduce non-uniform time deviations—sometimes by hours, sometimes by days—if there’s a bug in how offsets or join keys are generated for time grains. The frontend display format switch just toggles between raw and formatted values, but the underlying timestamp may already be shifted by the backend logic.

Recent changes to time offset and comparison logic have made this code more complex and may have introduced these bugs. To debug, inspect the DataFrame before and after normalization/offset application in the backend, check if offsets are being double-applied or misapplied, and review how join keys are generated for your time grain. This is not a config issue, but a subtle bug in the backend’s time-handling logic for visualizations. More details and debugging suggestions are in this issue thread.

If you need a workaround, check your dataset’s offset and time shift settings, and try to isolate a minimal dataset and chart config that reproduces the issue. The frontend logic for switching display formats is not the root cause, but it exposes the backend bug.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}