SceneTimeRange: Preserve explicit timezone values in URL state

[ivanortegaalba]

Problem

Dashboard links with "Include current time range" are not preserving timezone settings when navigating between dashboards. This affects users who set their dashboards to use "browser" timezone or other explicit timezone values.

When a dashboard has timezone set to "browser" and a user clicks a dashboard link:

• Expected behavior: Target URL contains timezone=browser
• Actual behavior: Target URL has timezone=Europe%2FMadrid (or user's local timezone)

Root cause:
The SceneTimeRange.getUrlState() method was calling this.getTimeZone() which resolves timezone values for calculations. This method:

• Returns the explicit state.timeZone value if set
• Otherwise resolves from parent scenes
• Falls back to getTimeZone() from @grafana/data

The problem is that getTimeZone() resolves "browser" to the actual browser timezone (e.g., "Europe/Madrid"). When this resolved value is used in URL state, it becomes permanent in the URL, losing the user's preference for "browser" timezone.

Why this matters:

• "browser" timezone means "always use my current browser's timezone"
• Resolving it to "Europe/Madrid" makes it a fixed timezone
• If the user travels or switches devices, the timezone won't update
• This breaks the semantic meaning of the "browser" setting

Related:

• Customer report: Dashboard links not preserving timezone with scenes enabled
• Works correctly with scenes disabled (old dashboard implementation)
• Grafana PR required: Preserve timezone in processQueryParamsForDashboardLoad()

Solution

Modified SceneTimeRange.getUrlState() to preserve explicit timezone values:

// Before: Always resolved timezone
timezone: this.getTimeZone()

// After: Preserve explicit value when set
timezone: this.state.timeZone !== undefined ? this.state.timeZone : this.getTimeZone()

How this works:

1. If state.timeZone is explicitly set (e.g., "browser", "UTC", "America/New_York"), preserve it in the URL
2. If state.timeZone is undefined (not set), fall back to getTimeZone() to resolve from parent or default
3. This ensures semantic timezone values like "browser" are preserved in URLs
4. Maintains backward compatibility: scenes without explicit timezone still get resolved values

What doesn't change:

• Internal timezone resolution for calculations still uses getTimeZone() (unchanged)
• Time range calculations remain accurate (unchanged)
• Default timezone behavior when no timezone is set (unchanged)
• All existing tests continue to pass

How to test

1. Create a dashboard with timezone set to "browser"
2. Add a dashboard link with "Include current time range" enabled
3. Click the dashboard link
4. Verify: Target dashboard URL contains timezone=browser (not resolved)
5. Verify: Target dashboard correctly displays in browser timezone
6. Change dashboard timezone to "UTC" and repeat
7. Verify: URL contains timezone=UTC
8. Create a dashboard without explicit timezone (undefined)
9. Click a dashboard link
10. Verify: URL contains the resolved timezone (e.g., timezone=America%2FNew_York)
11. Run test suite: yarn test SceneTimeRange.test --no-watch

Edge cases to verify:

• Dashboard with timezone=browser → Link URL has timezone=browser
• Dashboard with timezone=UTC → Link URL has timezone=UTC
• Dashboard with no timezone set → Link URL has resolved timezone (backward compatible)
• Switching between timezones preserves the selection in navigation

📦 Published PR as canary version: 6.39.9--canary.1279.18576011857.1

✨ Test out this PR locally via:

npm install @grafana/[email protected]
npm install @grafana/[email protected]
# or 
yarn add @grafana/[email protected]
yarn add @grafana/[email protected]

[dprokop]

@ivanortegaalba - after testing I don't think this PR is fixing the problem. The problem is in the url time range macro implementation, not in the SceneTimeRange. The maro interpolates browser time range to the actual IANA time zone name:

https://github.com/grafana/scenes/blob/main/packages/scenes/src/variables/macros/timeMacros.ts#L24

[dprokop]

Here's recording done after using the canary scenes version:

Screen.Recording.2025-10-17.at.11.54.20.mov