Temporal filters and granularity can diverge from the chart x-axis when multiple datetime columns exist

[ishimasar]

Bug description

Summary

Charts backed by datasets with multiple datetime columns can end up with time_range / from_dttm–to_dttm and granularity driven by the wrong column when dashboard native filters apply TEMPORAL_RANGE to a non–x-axis datetime (or when several temporal filters are present).

That yields queries where the visible x-axis does not match the time bounds or grouping actually used.

Root cause (high level)

1. QueryObjectFactory._process_time_range could fall back to the first TEMPORAL_RANGE clause even when the chart’s BASE_AXIS was a different datetime column, so another column’s bounds could become the main time_range.
2. QueryContextFactory could let granularity be inferred from dashboard context in a way that rewrote grouping / series away from the x-axis temporal column, and could strip or overwrite temporal filters in ways that dropped legitimate secondary datetime filters.

Intended behavior

• Prefer TEMPORAL_RANGE on the chart x-axis (BASE_AXIS) when resolving time_range.
• If the x-axis is known but no TEMPORAL_RANGE targets that axis, do not adopt another column’s TEMPORAL_RANGE as the main chart time range.
• When the x-axis is a temporal column, pin granularity to that x-axis column so grouping stays aligned with the axis.
• When deduplicating temporal filters for the main axis, preserve TEMPORAL_RANGE on other datetime columns (secondary time dimensions).
• When propagating time_range into existing filters, only update the TEMPORAL_RANGE row that matches the active granularity, and compare filter col values whether they are plain strings or adhoc column dicts (sqlExpression / label).

Implementation reference

• superset/common/query_object_factory.py(vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/code/electron-sandbox/workbench/superset/common/query_object_factory.py): x-axis–aware _process_time_range, adhoc-safe column matching.
• superset/common/query_context_factory.py(vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/code/electron-sandbox/workbench/superset/common/query_context_factory.py): lock granularity to x-axis temporal column, narrow filter removal / time_range application, adhoc-safe column matching.
• tests/unit_tests/common/test_query_object_factory.py(vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/code/electron-sandbox/workbench/tests/unit_tests/common/test_query_object_factory.py): unit tests for _process_time_range (no wrong fallback, legacy fallback when no axis, multi-filter preference, adhoc col dict).

Commits

• fix: align granularity with x-axis temporal column and preserve secondary dttm filters
• test: cover QueryObjectFactory._process_time_range x-axis selection

How to reproduce (click-by-click template)

Fill in the bracketed placeholders for your environment. Remove steps that do not apply (e.g. if you reproduce via API only).

1. Dataset: Create or use a virtual / physical dataset with at least two datetime columns, e.g. [ColumnA_dttm] and [ColumnB_dttm] (replace with real names).
2. Chart

• Create a time-series (or mixed) chart that uses [ColumnA_dttm] as the x-axis / time column (BASE_AXIS).
  -Save the chart as [Chart name].

3. Dashboard
   -Create a dashboard [Dashboard name] and add [Chart name].
4. Native filter (critical)

• Add a dashboard native filter of type Time column / Time range (wording depends on Superset version) scoped to [ColumnB_dttm] (the non–x-axis datetime).
• Set an explicit range, e.g. [Start] to [End] that is narrower or different from any range you might set on ColumnA.

5. Observe

• With no separate native filter on [ColumnA_dttm], open the chart on the dashboard.
• Note: axis label / grain, data span, and SQL or query payload (if available) for time_range, granularity, and filters.

6. Expected

• Main query time bounds and grouping should follow [ColumnA_dttm] (the chart x-axis), not [ColumnB_dttm]’s dashboard filter.
  Filters on [ColumnB_dttm] should still apply as secondary temporal constraints where applicable, without replacing the x-axis time range.

7. Actual (before fix)

• Describe what you see, e.g.:
  • Query uses [ColumnB_dttm] range for from_dttm / to_dttm, or
  • granularity / GROUP BY does not match [ColumnA_dttm] on the x-axis, or
  • Secondary temporal filter incorrectly removed.

8. Environment (fill in)

• Superset version: [e.g. 4.x.x]
• Chart plugin / viz type: [e.g. ECharts Timeseries]
• Database engine: [e.g. Postgres / BigQuery / …]
• Feature flags (if any): [list]
• Browser: [e.g. Chrome 123]

Verification checklist (for reviewers)

• Multiple datetime columns on one dataset.
• Native TEMPORAL_RANGE only on non–x-axis column.
• X-axis remains correct; secondary datetime filter behavior is sensible.
• Adhoc x-axis / filter column definitions still match correctly.

Screenshots/recordings

No response

Superset version

master / latest-dev

Python version

3.11

Node version

18 or greater

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]

Hi @ishimasar! I'm Dosu and I’m helping the superset team.

This is a well-documented bug report. For context, several related fixes have already landed in the codebase over the past few months that address parts of this problem:

• PR fix(timeshift): Add a more reliable strategy for correct temporal col #36309 (Dec 2025) refactored _get_temporal_column_for_filter to use a deterministic, multi-strategy approach — first checking the TEMPORAL_RANGE filter list, then falling back to granularity, then x_axis_label, and removed the unreliable datasource column fallback that was a source of ambiguity [1].
• PR fix(native-filters): update TEMPORAL_RANGE filter subject when Time Column filter is applied #36985 (Feb 2026) fixed merge_extra_form_data to properly update the TEMPORAL_RANGE filter subject when a Time Column native filter selects a different temporal column [2].
• PR fix(mcp): add TEMPORAL_RANGE filter for temporal x-axis in generate_chart #38978 (Mar 2026) ensured chart generation explicitly sets granularity_sqla to the x-axis column when it's temporal and adds a matching TEMPORAL_RANGE adhoc filter [3].

As of the current code, _process_time_range does prioritize BASE_AXIS columns — it looks for a TEMPORAL_RANGE filter matching the x-axis label first, and only falls back to the first TEMPORAL_RANGE filter if none matches [4]. Similarly, _apply_granularity in query_context_factory.py checks whether the x-axis is temporal and uses it as the column to anchor the temporal filter on [5].

That said, a few gaps remain that align with what you've described:

1. Adhoc column matching — when the x-axis or filter column is an adhoc column dict (with sqlExpression/label), the string comparison against plain column names can fail, causing the BASE_AXIS preference logic to miss the match.
2. Secondary temporal filter preservation — the deduplication logic removes a temporal filter to prevent duplicates, but may inadvertently strip a legitimate TEMPORAL_RANGE on a different datetime column rather than preserving it as a secondary constraint.
3. Single temporal filter design constraint — Superset currently supports only one temporal filter slot per chart by design [6], which means independent time ranges on multiple datetime columns aren't natively supported.

Are you planning to open a PR for the fixes described in this issue? The commit messages you mentioned ("fix: align granularity with x-axis temporal column and preserve secondary dttm filters") suggest you may already have a patch. If so, it would be great to see how you handle the adhoc column dict comparison and the secondary filter preservation — those are the trickiest parts based on the current implementation.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[ishimasar]

@dosu
Thanks for the context and for linking those related PRs — they’re helpful background.

Yes, we’re planning to open a PR. The patch we have is aimed specifically at the gaps you called out:

Adhoc column matching — we normalize filter / axis column identifiers (string vs adhoc dict with sqlExpression / label) before comparing to get_xaxis_label / temporal columns, so BASE_AXIS preference doesn’t silently miss when col is an adhoc object.

Secondary temporal filters — we only remove / rewrite the TEMPORAL_RANGE that corresponds to the chart’s anchored temporal column (x-axis when temporal), and we avoid dropping unrelated TEMPORAL_RANGE clauses on other datetime columns where the previous dedupe was too aggressive.

Granularity vs x-axis — when the x-axis is a known temporal column, we align granularity with that column so inferred dashboard granularity doesn’t rewrite GROUP BY / series away from the axis the user sees.

We’re aware of the single temporal filter slot design constraint; the change is about not mis-attributing that slot (or granularity) to the wrong column when multiple datetimes exist, not about adding fully independent multi-range semantics.

We’ll link the PR here once it’s up so you can compare with #36309, #36985, and #38978.

[dosubot]

Thanks for the detailed breakdown — the approach sounds solid across all three areas.

The adhoc column normalization is particularly important. The current matching in _process_time_range compares against the string returned by get_x_axis_label(), but filter col values can be either plain strings or adhoc dicts with sqlExpression/label keys [1]. A mismatch there silently defeats the BASE_AXIS priority logic, so normalizing both sides before comparison should close that gap cleanly.

On the secondary filter preservation — narrowing the removal scope in _apply_granularity to only strip the TEMPORAL_RANGE matching the anchored column [2] makes sense. The key thing to watch for is that the remaining secondary TEMPORAL_RANGE clauses still get passed through to the SQL generation layer as WHERE constraints rather than being silently dropped elsewhere in the pipeline.

Looking forward to seeing the PR — linking it here will make it easy to cross-reference with the prior fixes.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.