Define the records before counting
Preserve the original timestamp, its stated offset or zone, source system and what the event means. Identify the reporting time zone used by each platform. A payment settlement date, job completion time and inquiry arrival are different events even when all are labeled “date.”
A worked example
Fictional test: 2026-10-01T00:30:00Z is September 30 at 17:30 in a UTC−07:00 display. Filtering one file by October 1 UTC and another by September 30 local time can separate the same event. A bare 10/01/26 value adds another ambiguity because the file does not establish its intended format or zone.
Resolve the gap in evidence
Choose a reporting zone and normalize a separate display field while retaining the original. Use explicit offsets or a documented zone-aware conversion rather than subtracting a fixed number of hours year-round. Flag timestamps without enough context. Do not rewrite the source file in place while experimenting with conversions.
Check whether it worked
Test known boundary cases near midnight and relevant daylight-saving transitions using a supported date-time tool. Confirm that duration calculations use actual instants, not unrelated displayed dates. Reconcile counts before and after normalization and explain any moved reporting-day totals. If dates still disagree, inspect whether the systems are recording different event milestones.
Put it to work
A record you can use
- Source timestamp and meaning
- Original offset/zone
- Chosen reporting zone
- Normalized value and method
- Midnight boundary and count checks
Plain text. No email required. Store completed records in your approved business systems.
Next useful step
Need help applying this to your marketing? A strategy call starts with your business and the evidence you have.
Talk through your next step →For a general editorial question, email Chris. Please leave out customer details. Questions are private, and no response time is promised.