master branch: datetime field shows incorrect time in Bar Charts and Scatter Plot with inconsistent deviations (vs correct time in SQL Lab)

[Alice-608]

Bug description

In the latest master branch of Apache Superset, datetime-type fields exhibit inconsistent and incorrect behavior when used in visualizations, compared to raw SQL queries in SQL Lab:

SQL Lab: When executing a raw SELECT query on a table containing datetime data, the time values are returned correctly as stored in the database.
Datasets & Charts: When the same data is used to create a dataset and visualizations (eg:Bar Charts, Scatter Plots):
The datetime values displayed on the chart are incorrect.
The time deviation is inconsistent across different data points. Some timestamps are shifted by hours, while others are shifted by days, with no uniform offset.

Concrete example from the provided screenshots:

This discrepancy breaks the reliability of time-based visualizations and makes it impossible to trust the results.

Expected Behavior
Datetime fields should display consistent, correct time values in both SQL Lab and all visualizations, regardless of the time grain or grouping used.
The time shown in the chart should exactly match the time returned by the raw SQL query.

Actual Behavior
SQL Lab: Time values are correct and match the source data.
Charts:
Time values are incorrect and do not reflect the source data.
Deviations are inconsistent across different data points, with shifts of varying hours and even days.

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]

The inconsistent datetime shifts you’re seeing in charts versus SQL Lab are caused by dataset-level offset and time shift adjustments applied during visualization processing. SQL Lab returns raw database values, but chart queries go through a normalization step that applies any configured offset (like the “Hours Offset” in the Edit Dataset modal) and time shift metadata to datetime columns. If these settings are misconfigured or set inconsistently, you’ll see unpredictable shifts across data points in charts, while SQL Lab remains unaffected. This is a known issue, especially when working across timezones or using relative time filters, since Superset currently calculates ranges in UTC and doesn’t always display timezone metadata in charts or filters. There’s ongoing work to improve timezone handling and add user timezone selection, but for now, check your dataset’s offset and time shift settings and ensure they’re consistent and correct for your use case. More details and proposals are discussed here and here.

To reply, just mention @dosu.

---

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

   

[Alice-608]

@dosu
Thank you for your response and suggestions!
Upon further investigation, I found that the core characteristics of this issue do not align with the assumption of "incorrect dataset-level offset configuration":
In the Bar Chart and Scatter Plots, the time offset for each data point is completely inconsistent, with no uniform pattern:
Original time 2026-02-15 16:30:00 → Displayed in chart as 2026-02-16 09:00:00 (offset of ~+16.5 hours)
Original time 2026-02-15 10:00:00 → Displayed in chart as 2026-02-15 20:00:00 (offset of +10 hours)
Original time 2026-02-11 14:20:00 → Displayed in chart as 2026-02-12 04:40:00 (offset of ~+14.33 hours)
This phenomenon of inconsistent time offsets per data point clearly cannot be explained by a "unified offset configuration." Instead, it appears to be a non-deterministic conversion error introduced in the time-handling logic of the master branch.

[dosubot]

You're right—what you're seeing can't be explained by a unified offset or time zone config. Superset's chart pipeline applies normalization and offset logic to datetime columns that SQL Lab does not, but those should always result in consistent, uniform shifts if configured correctly.

The inconsistent, per-row time shifts you describe point to a bug in the backend's time-handling logic for visualizations. In the master branch, chart queries go through a normalization step (normalize_dttm_col) that applies dataset offsets and time shifts, and—if time comparisons are enabled—joins additional offset DataFrames using generated join keys based on the time grain. If there's a bug in how these join keys are generated or how offsets are parsed/applied, it can cause non-uniform, even non-deterministic, shifts per data point, exactly as you describe. This logic is separate from SQL Lab, which just returns raw database values without any of these transformations.

Recent changes to time offset and comparison logic (including PRs like #30002 and #37698) have made this code more complex, especially around parsing human-readable time shifts and joining offset DataFrames. If the join columns or offset calculations are misaligned, you can get the kind of inconsistent results you're seeing (backend code reference, offset normalization, date parsing).

To debug, I'd suggest: 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. If you can, try to isolate a minimal dataset and chart config that reproduces the issue, and see if the problem persists with different time grains or after disabling time comparisons.

This looks like a regression or subtle bug in the time offset/join logic for chart queries, not a config issue.

To reply, just mention @dosu.

---

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