## TL;DR
Decide which timezone the business reports in, then make every layer use it. Check how the database stores timestamps, whether the dashboard tool converts them for the viewer, and where the default filter value such as today is computed. A default computed in one timezone against data stored in another shifts the window, so the report quietly covers the wrong hours until someone reconciles it by hand.

```text
dashboard date filter defaults wrong: timezone conversion error in report fix
```

## Use this when
- Report totals differ between viewers in different locations, or between the live dashboard and its scheduled delivery.
- Daily numbers are consistently shifted, with late evening activity appearing on the wrong day.
- The mismatch appeared after a database migration or a move to UTC storage.

## Not for this skill when
- The date filter excludes all data because of a wrong field mapping. Fix the mapping instead of timezone settings.
- Dates are stored as plain dates with no time component and no conversion is involved. Look at the filter logic itself.

## Steps
1. Pick one known event with a certain timestamp and trace how it appears in the database, in the dataset, and on the dashboard for a viewer. Verify: you can name the layer where its displayed day changes
2. Record the intended reporting timezone and check the database session and storage convention against it. Verify: storage and session settings are documented and consistent
3. Adjust the dashboard or dataset conversion setting so timestamps convert once, to the reporting timezone, and not twice or never. Verify: the known event now displays on the correct day
4. Check how the default filter value is computed and set it explicitly in the reporting timezone where the tool allows. Verify: opening the dashboard at a boundary hour defaults to the intended day
5. Compare a full day total between the dashboard and a reference query written in the reporting timezone. Verify: the totals match exactly for the same day definition
6. Test the scheduled delivery path, since its server timezone can differ from the viewer experience. Verify: a test delivery shows the same day window as the interactive dashboard

## Why it happens
Timezone bugs survive because every layer looks correct in isolation and the totals are plausible, just shifted. They are found by reconciliation, not by errors, which is why one traced event and one reference query are worth more than reading every setting. Once the reporting timezone is chosen and written down, most of the fix is removing the extra or missing conversion that disagreed with it.

Timestamp handling crosses three boundaries, storage in the database, conversion in the BI tool, and the viewer or server timezone that defines defaults like today or last week. If timestamps are stored in UTC and the tool displays them in a local zone without the report author realising, filters and groupings split days at the wrong instant. Scheduled deliveries add a fourth boundary, the server timezone at send time, which is why a dashboard can look right interactively and wrong in the morning email.

Field notes for dashboard estates generally. The most valuable incident habit is to separate the layers before changing anything, source data, dataset or model, dashboard definition, and delivery or viewing layer, and to prove which layer is wrong with one test per layer. Most dashboard failures are reported at the viewing layer and fixed at the wrong layer at least once before the real cause is found. A one line layer verdict in the incident note, with the test that proved it, saves the next engineer the same detour when the symptom recurs.

A second general habit is to keep a known good reference for every important dashboard, one number per dashboard that an owner can check against the source system in under a minute. Reconciliation beats error hunting for the silent failures, wrong definitions, shifted dates, stale caches, because those produce no error at all. Dashboards with a reference check get their silent failures found by the team, while dashboards without one get them found by the audience, which is the difference between maintenance and incident response.
## Variants and edge cases
### dashboard date filter wrong day timezone conversion fix
The wrong day phrasing matching the visible symptom.
### report totals shifted UTC storage dashboard timezone
The storage conversion variant after a UTC migration.
### scheduled report different dates than live dashboard timezone
The delivery variant where the server timezone differs.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IMGCHxyFSQGNy2LpBemtcg