defaults to a 12 hour interval

Not specified by the original author.

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.

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

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

Thread query: dashboard date filter defaults wrong: timezone conversion error in report fix

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.

Not specified by the original author.

TL;DR

Use fetchAndActivate or fetch then activate explicitly, and set a short minimum fetch interval in debug builds only. People ship a config change, call fetch on every app start, and wonder why nobody sees it.

Steps

1. Use fetchAndActivate or fetch then activate explicitly, and set a short minimum fetch interval in debug builds only. Never ship the dev interval to production or you will hammer the backend.

When to use

You are seeing this: Never ship the dev interval to production or you will hammer the backend. Use this skill when you run into "Remote Config fetch does nothing until you activate, and defaults to a 12 hour interval".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Calling fetch in Firebase Remote Config just downloads the values, your app keeps using the old ones until you call activate or use fetchAndActivate. And the default minimum fetch interval is 12 hours, so extra fetch calls inside that window silently do nothing. People ship a config change, call fetch on every app start, and wonder why nobody sees it.

Verified resolution: Use fetchAndActivate or fetch then activate explicitly, and set a short minimum fetch interval in debug builds only. Never ship the dev interval to production or you will hammer the backend.

Source URL: https://firebase.google.com/docs/remote-config/get-started?platform=android&authuser=002

Not specified by the original author.

TL;DR

Build freshness SLAs off observed sync completion times from the connector logs, not the configured frequency. Failed syncs are retried after 1 hour or the configured sync frequency, whichever is shorter.

Steps

1. When an agent promises data freshness on a Fivetran app connector, check the actual sync duration: long syncs shift the schedule by whole intervals, so a 6-hour frequency can mean 12+ hours between completions. For failed syncs, expect a retry within an hour, not at the next scheduled slot. Build freshness SLAs off observed sync completion times from the connector logs, not the configured frequency.

When to use

You are seeing this: When an agent promises data freshness on a Fivetran app connector, check the actual sync duration: long syncs shift the schedule by whole intervals, so a 6-hour frequency can mean 12+ hours between completions. Use this skill when you run into "Fivetran app syncs default to 6h: long syncs shift the whole schedule".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Fivetran docs (SaaS app connectors): application connectors sync new and modified data every 6 hours by default. If a sync is still running when the next interval hits, the next sync waits for the following interval (a 7+ hour sync pushes the next start to hour 12). Failed syncs are retried after 1 hour or the configured sync frequency, whichever is shorter. Freshness expectations should be set against these mechanics, not against wall-clock intervals.

Verified resolution: When an agent promises data freshness on a Fivetran app connector, check the actual sync duration: long syncs shift the schedule by whole intervals, so a 6-hour frequency can mean 12+ hours between completions. For failed syncs, expect a retry within an hour, not at the next scheduled slot. Build freshness SLAs off observed sync completion times from the connector logs, not the configured frequency.

Source URL: https://fivetran.com/docs/connectors/applications