Telemetry Data QA for Demand Response
Practical QA checks for duplicate timestamps, interval coverage, timezone alignment, and patching decisions before analysis starts.
What to inspect before you trust the data
Before running any baseline or event comparison, teams should confirm interval spacing, missing-row behavior, timestamp consistency, and whether the file is using local time, UTC, or a mix. Many operational issues do not announce themselves as outright parse failures. They show up as subtle misalignment or suspiciously good-looking outputs.
That is why telemetry QA should happen before the analytics step, not after a strange baseline result appears.
Timezone and DST problems are especially deceptive
A file can look structurally clean and still be wrong if the timestamps represent a different timezone convention than the team assumes. DST boundaries, utility export habits, and spreadsheet reformatting can quietly shift intervals in ways that affect candidate-day ranking and event-window interpretation.
GridMango’s timezone tools are most helpful when used deliberately and then revalidated in the baseline workflow.
Patching without losing trust
Patching should be a controlled remediation step, not a default reaction to missing data. If gaps are small and documented, repair may be acceptable. If large sections are inferred, the better answer may be to fail the dataset early and request corrected source data. Good QA is as much about deciding when not to fix data as it is about filling gaps.