Time zone visibility in dashboard periods: Why periods differ by user location
In dashboards, currently running survey periods can display differently depending on each user’s local time. A period that has already started in one time zone may still be in the future in an earlier time zone and will be correctly hidden there.
Who is this article for?
- Admins and reporting users who work with dashboards
- Global teams with participants across multiple time zones
Symptoms
- In one time zone, the period filter shows 4 periods.
- At the same moment, users in an earlier time zone see only 3 periods.
- The “current” period appears to be missing for those users.
Root cause
The period filter respects the signed‑in user’s local time. If a cycle’s start time is still in the future in the user’s local time, that period is not shown in the filter.
How the survey‑based period filter works
-
Relevant surveys per dashboard
Only surveys whose questions are used in the dashboard’s charts are considered.
-
Excluding future cycles
Cycles with a start time after the user’s current local time are not shown.
-
Merging periods
Overlapping cycles or immediately consecutive cycles are merged. The evaluation uses visible calendar dates rather than technical timestamps.
-
Selection
After merging, the 100 most recent periods are made available to the filter.
When can an expected period be missing?
- None of the survey’s questions are used in any chart on the dashboard
- The period is still in the future in the user’s local time
- The user does not have access to the underlying survey
FAQ
-
Why does Team A see four periods while Team B sees only three?
Because the “current” period’s start time is still in the future for Team B in their local time.
-
Can we force time‑zone‑independent visibility?
No. Visibility is intentionally based on local time so no one sees a period as “current” before it has actually started for them.
-
We operate globally. How can we avoid confusion?
Communicate start times in both UTC and local times and plan start windows so key regions become visible at the same time.
Best practices for global setups
- Always communicate start times in UTC plus local times
- Where possible, choose start times so key regions fall within “today” simultaneously
- For staggered rollouts, clearly indicate when a period becomes visible by region