Cheatsheet

Timestamp formats: legacy Google Ads → RFC 3339

The Data Manager API accepts exactly one timestamp shape: RFC 3339. The legacy world accepted half a dozen. This page maps each old format to its converted form.

The target format

event_timestamp: "2026-06-20T15:07:01Z"       // UTC ("Z")
event_timestamp: "2026-06-20T10:07:01-05:00"  // or explicit offset

• T between date and time (a space is invalid)
• An explicit offset or Z is mandatory — naive timestamps are rejected
• Fractional seconds optional (0, 3, 6, or 9 digits)

Conversion table

The three timezone pitfalls

1. Naive timestamps are not UTC

A timestamp without an offset means "whatever timezone the file assumed" — usually the account timezone, not UTC. Converting a US-Eastern timestamp as if it were UTC shifts every conversion by 4–5 hours, which silently moves late-evening conversions to the wrong day and breaks day-level reporting. The converter refuses to guess: if no timezone information exists, it asks you to pick one.

2. DST changes the offset mid-file

America/New_York is −05:00 in January and −04:00 in July. If a file spans a DST boundary, a fixed offset like -0500 is wrong for part of the rows. Prefer timezone IDs (America/New_York) over raw offsets — the converter resolves each row's offset at that row's date.

3. MM/dd vs dd/MM

03/04/2026 is March 4 in US format and April 3 in most of the world. This tool parses US-style MM/dd/yyyy, and when it detects a day-first date (day > 12) it raises an error instead of guessing. If your export uses day-first dates, switch it to ISO yyyy-MM-dd.

Related rules

• Timestamps in the future are flagged — Google rejects conversions dated after upload time.
• Timestamps older than the 90-day click lookback window are flagged — the conversion will likely not be attributed.

Convert and validate your file in the converter, or see the full field mapping.