EVENT_TIME_TOO_OLD
The conversion timestamp is outside Google Ads' accepted time range. Learn why event times get rejected — 90-day limits, timezone issues, Unix vs ISO format confusion — and how to fix it.
Common Causes
| # | Cause | Likelihood | Details |
|---|---|---|---|
| 1 | Conversion date outside 90-day window | Very Common | The conversion timestamp you provided is more than 90 days in the past. Google Ads does not accept offline conversions with event times older than 90 days from the upload date. |
| 2 | Timezone format error | Common | The timezone offset in your timestamp is wrong or missing. Google Ads expects the format 'yyyy-MM-dd HH:mm:ss±zzzz' (e.g., '2024-01-15 14:30:00-0500'). A missing or incorrect timezone offset can cause the calculated UTC time to fall outside the window. |
| 3 | Unix timestamp vs ISO format confusion | Common | Sending a Unix timestamp (like 1705340400) when Google expects a formatted datetime string, or vice versa. The Google Ads API expects the datetime format, not Unix timestamps. |
| 4 | Historical data import attempt | Moderate | Attempting to bulk-import historical conversion data from before your tracking setup. Any conversion older than 90 days will be rejected regardless of how valuable the data would be. |
| 5 | Date field mapped to wrong column | Less Common | In CSV uploads, the conversion time column might be mapped to a different field (like 'Created Date' instead of 'Conversion Date'), pulling in an older timestamp than intended. |
What It Means (Plain English)
The conversion timestamp in your upload is outside Google Ads’ accepted range. Most commonly, the conversion date is more than 90 days ago. Google Ads will not process this conversion because the data retention window has passed.
Note: This is different from EXPIRED_GCLID, which checks the click date. EVENT_TIME_TOO_OLD checks the conversion date — when the conversion event actually occurred.
How to Fix It
Step 1: Verify Your Date Format
Google Ads requires this exact format:
yyyy-MM-dd HH:mm:ss±zzzz
Examples:
✓ 2024-01-15 14:30:00-0500 (EST)
✓ 2024-01-15 19:30:00+0000 (UTC)
✓ 2024-07-22 09:15:00+0530 (IST)
✗ 2024-01-15 (missing time)
✗ 2024-01-15T14:30:00-05:00 (ISO 8601 — wrong for Google)
✗ 1705340400 (Unix timestamp — wrong format)
✗ 01/15/2024 2:30 PM (US date format — wrong)Step 2: Check the Conversion Date vs. Click Date
Make sure you’re sending the conversion date (when the sale closed, job was booked, contract was signed) — not the click date, not the lead creation date, and not the upload date.
| Date | What It Is | Where It Goes |
|---|---|---|
| Click date | When the ad was clicked | Implicit in the GCLID (don’t send separately) |
| Conversion date | When the conversion happened | conversion_date_time field ← this one |
| Upload date | When you’re uploading | Not sent — implicit |
Step 3: Filter Old Records
Add a pre-upload check:
conversion_date = parse_date(record.conversion_time)
days_old = (today - conversion_date).days
if days_old > 85:
exclude_record("Conversion time too old for upload")Step 4: Check Timezone Handling
If your pipeline stores dates in UTC but your conversion times are in local time (or vice versa), the calculated age may be off by hours — which matters for records near the 90-day boundary.
How TUOCA Prevents This
The Upload Offline Conversions App handles timestamp validation automatically:
- Format enforcement — All timestamps are converted to Google’s required format with correct timezone offsets before upload
- Age validation — Conversions older than 85 days are flagged and excluded from the upload batch
- Source timezone mapping — TUOCA maps source data timezones correctly during relay configuration, preventing offset errors
- Activity log transparency — Filtered records appear in the activity log with clear reasons, so you can audit what was excluded and why