[BUGFIX] (dashboards): apply dashboard.spec.timezone to TimeZoneProvider

[colivi]

Description

"dashboard.spec.timezone" was applied only to the toolbar time picker ("DashboardApp" → "toolBarTimezone"), while charts used "TimeRangeProviderWithQueryParams" → "useTimeZoneParams('local')".

Result: the picker could show GMT+0 / UTC while panels still formatted in browser local.

Approach

Keep time range and timezone as separate concerns (credits to Celian):

• "TimeRangeProviderWithQueryParams" / "TimeRangeProviderBasic" → range only
• "TimeZoneProvider" is composed at the view layer

TimeRangeProviderWithQueryParams
└── TimeZoneProvider ← ViewDashboard / ViewExplore
└── charts + toolbars (useTimeZone)

Fix

• ViewDashboard: resolve spec.timezone || userPreferenceTimezone || 'local' via useTimeZoneParams, wrap children in TimeZoneProvider
• ViewExplore: same composition (URL / local only — no dashboard spec)
• Sticky toolbar: seed useTimeZoneParams from TimeZoneProvider context (no hardcoded 'local')
• Do not nest timezone inside the TimeRange helpers

Hierarchy (charts + toolbar)

dashboard.spec.timezone > user preference > 'local' (URL ?tz= still overrides via useTimeZoneParams)

Checklist

• Pull request has a descriptive title and context useful to a reviewer.
• Pull request title follows the [<catalog_entry>] naming convention.
• All commits have DCO signoffs.

[jgbernalp]

This hierarchy means a dashboard defining a timezone will "lock it" disallowing the user to use a custom one?

[colivi]

Yes for the default view, by design (see docs/concepts/timezone.md):
spec.timezone > user preference > local, so ops dashboards can pin UTC for everyone.

Users can still override at runtime via the time-range timezone control / ?tz= (useTimeZoneParams), which takes precedence over the resolved initial value.

[jgbernalp]

This is a breaking change for consumers of this provider as it no longer uses the timezone provider, this creates the duplication under other components. Instead of removing this, we can add another provider in the case an override (the dashboard spec timezone) is needed. As the hook will take the value from the closest provider

[colivi]

Good point, restored TimeZoneProvider inside TimeRangeProviderWithQueryParams so existing consumers keep working.
ViewDashboard nests an additional provider with spec.timezone || user pref, so useTimeZone() picks the closest override without a breaking API change.

[shahrokni]

⚠️ I'd like to review. Please keep it on hold and do not merge!

[shahrokni]

Suggestion

Could it be simplified?

return (dashboardTimezone?.trim() || userPreferenceTimezone?.trim() || "local");

[shahrokni]

I am not sure why the second TimeZoneProvider has been added. In the hierarchy, the TimeRangeProviderWithQueryParams already provides the tz provider.

Apart from that, in my opinion, an ideal implementation would take the tz from

1. try to fetch tz from the query params, does not exist?
2. try to fetch it from spec.tz , does not exist?
3. try to fetch it from the user preferences, does not exits
4. set it to local
5. Update tz to the last read value, establish a loop of retrieve/update. (at this point the tz could not be technically undefined anymore. It is showing either spec, user prefrences, or local)

Whenever the time zone is edited by the user the tz query param should be updated. Subsequently, the updated tz should be retrieved and used accordingly. Let's take a look at the fllowing code:

/* initialTimeZone  is set by spec || user preference || local */
export function useTimeZoneParams(initialTimeZone?: string): { timeZone: string; setTimeZone: (tz: string) => void } {
  const [query, setQuery] = useQueryParams(timeZoneQueryConfig, { updateType: 'replaceIn' });
  const { tz } = query;

   /* >>>>> interesting line <<<<< */
  const timeZone = (tz as string | undefined) ?? initialTimeZone ?? 'local';

  const setTimeZone = useCallback(
    (newTz: string) => {
      setQuery({ tz: newTz });
    },
    [setQuery],
  );

  return { timeZone, setTimeZone };
}

[shahrokni]

Tested and no issue found

Scenario 1

Changed the tz

1. dashbaord was updated
2. query param was updated

Scenario 2

Copy/Paste the url and open it in a new tab
tz reflects in url, toolbar and dashbaoard