Align reporting dates and time zones

Compare the same instants and reporting boundaries in named time zones before comparing daily totals. Store an inclusive start and exclusive end, document the attribution clock, and freeze a shared refresh cutoff. A date label by itself is insufficient.

One instant can belong to two dates

Synthetic example RP-TZ-01. The following conversions were checked with Python zoneinfo and the IANA zones America/New_York and America/Los_Angeles.

The October event falls in an October New York report and a September Los Angeles report. Applying New York’s summer offset to January would put the second event on the wrong New York date.

Define boundaries as instants

For September 2026 in New York, use 2026-09-01T00:00:00-04:00 ≤ timestamp < 2026-10-01T00:00:00-04:00. In UTC this is 2026-09-01T04:00:00Z through, but excluding, 2026-10-01T04:00:00Z. A row exactly at the end belongs to the next period. Half-open windows prevent an endpoint from belonging to both adjacent periods.

On November 1, 2026 in New York, 01:30 occurs twice: once at UTC−04:00 and once at UTC−05:00. The two instants are 05:30Z and 06:30Z. Preserve an offset or UTC instant when local times are ambiguous. Local calendar days across daylight saving transitions can contain 23 or 25 hours.

Match the reporting clock

• Record each source’s configured reporting time zone.
• Identify event time, conversion time, and interaction time; do not treat them as interchangeable.
• Write the late-arrival and restatement rule. Compare snapshots captured after the same agreed cutoff.
• Test a row before the start, exactly at the start, just before the end, and exactly at the end.
• Repeat a winter and summer test and both sides of a daylight saving transition.

Google Analytics uses the property time zone while Google Ads uses the account time zone. Attribution and counting settings can also differ. A timing difference can be legitimate; changing a time zone does not reconcile different metric definitions.