How are time column filters supposed to work?

[vhogberg]

@dosu

I'm having trouble with time column filters/display controls. I'm guessing your supposed to be able to switch for example which column is used on the x-axis of a timeseries chart. So being able to switch between order_date and delivery_date in a bar chart for example. I keep running into weird results though with the y-axis going up into the millions unexpectedly resulting in just one bar with the new column in switching to ending up in the legend, as if it was a metric.

What I'm doing:

1. Select a dataset which has multiple time columns in it
2. Create an 'x over time' bar chart using the default date time column
3. Add the bar chart to a dashboard
4. Add a time column filter
5. Change the time column to the non-default datetime and apply the filter -> expect to get the bar chart with the other datetime column defining the time aggregation, instead get a bar chart with (?) two metrics:

With default datetime:

Switching via a time column filter to use the non-default datetime column:

It's within the same dataset, same format, so I'm not sure what's happening and if it's a genuine bug.

[dosubot[bot]]

What you're describing looks like a real bug — and a closely related one was recently identified and fixed.

How the Time Column filter is supposed to work:

When you apply a "Time Column" filter on a dashboard, it sends granularity_sqla via extra_form_data, which the backend maps to the granularity field in the query [1]. The intent is exactly what you expect: swap which column drives the time aggregation on the x-axis without changing anything else about the chart.

What's likely going wrong:

PR #42875 (merged 2026-08-20) describes a very similar symptom. When the Time Column is overridden via a dashboard filter, the backend method _apply_granularity was not only swapping the underlying SQL column but also renaming the x-axis column's label to the overridden column name. This desynchronized the pivot logic and the frontend series extraction, which both reference the x-axis by its original saved label. The result: ECharts doesn't recognize the new key as the x-axis, treats it as a numeric series (the timestamp in milliseconds → values in the millions/trillions), and the column ends up in the legend as if it were a metric [2].

That fix specifically targeted charts with Time Comparison configured, but the underlying mechanism — the label mismatch causing the chart to misinterpret the series — is the same pattern you're seeing. It's plausible the same _apply_granularity label-renaming issue affects your case even without Time Comparison, though I can't confirm that with certainty.

There was also a separate earlier fix in PR #36985 (merged 2026-02-04) where the Time Column filter was not updating the TEMPORAL_RANGE adhoc filter's subject, causing the selected column to be ignored entirely on certain chart types.

What you can try:

1. Check your Superset version — if you're on a build before 2026-08-20, the fix in fix(explore): keep x-axis label when overriding Time Column with time comparison #42875 isn't available yet. Upgrading to a recent build should help, especially if you also pick up fix(native-filters): update TEMPORAL_RANGE filter subject when Time Column filter is applied #36985.
2. As a workaround, open the chart in Explore, manually switch the x-axis column to the non-default datetime, and save a separate chart rather than relying on the dashboard Time Column filter.
3. If you're still seeing this on a build that includes both fixes, it would be worth filing a bug report with your exact Superset version, chart type, and whether the x-axis is configured as an adhoc column vs. a plain column selector — since the fix in fix(explore): keep x-axis label when overriding Time Column with time comparison #42875 specifically targets the adhoc (BASE_AXIS) x-axis path.

So your instinct that it's a genuine bug is correct. The root cause has been tracked and fixed for the Time Comparison case, and likely overlaps with your scenario.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[vhogberg]

Thanks, #42875 seems to have been the solution. I'm on 6.1 and only use official releases, so the fix isn't in yet.