Skip to main content
Three rules cover most timezone questions:
  • *_unix_timestamp fields are always UTC seconds. Never shifted by request parameters or network configuration.
  • Date-string fields and date bucketing use the timezone_id on the request (or the network default if omitted).
  • timezone_id shifts where date buckets begin and end. It does not transform individual event timestamps.

​
timezone_id in reporting requests

Reporting endpoints accept timezone_id in the request body to bucket events into days, hours, months, etc.

timezone_id: 67 (UTC)

Event at 2026-04-01 23:30 UTC → April 1 bucket.

timezone_id: 80 (America/New_York)

Same UTC timestamp (19:30 EST) → April 1.Event at 2026-04-02 03:30 UTC (23:30 EST) → April 1 under EST, April 2 under UTC.
from and to values are interpreted as 00:00:00 in the requested timezone_id — not midnight UTC. The same date-range string returns different totals depending on which timezone_id you pass.
No timezone_id? Reports fall back to the network default (reporting_timezone_id on GET /v1/networks/info). Pass it explicitly for predictable totals.

​
Finding the timezone ID

Pick your timezone from the full reference below, or fetch the live list from GET /v1/meta/timezones.
UTC offsets reflect each zone’s currently-effective offset and shift with DST. Use the offset as a hint, not a contract — fetch live values from GET /v1/meta/timezones if your application depends on the offset.
To fetch programmatically, call GET /v1/meta/timezones — the response is { "timezones": [...] }. Match on the timezone field (IANA identifier) — never timezone_name, which is a display string that shifts with DST.

​
Response timestamps

All response timestamp fields are Unix epoch integers in UTC — regardless of the timezone_id in the request.

​
Date strings in responses

Date strings appear in two specific places, both in YYYY-MM-DD HH:MM:SS format (no offset, no T separator): 1. Aggregated reports grouped by a time column — the string lives inside the columns array, bucketed by the request’s timezone_id:
2. Firehose stream — top-level date / click_date strings alongside Unix timestamps, in the network’s reporting timezone:
Conversion list endpoints (/networks/reporting/conversions and peers) and conversion/event webhooks include Unix timestamps only — no date string.

​
Daylight saving time

Queries spanning a DST transition are bucketed correctly (pre-transition hours as standard time, post-transition as daylight time). date and hour strings reflect local wall-clock time across the shift. Unix timestamps remain UTC and are immune.