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.
{
"from": "2026-04-01",
"to": "2026-04-30",
"timezone_id": 67,
"columns": [{ "column": "date" }]
}
timezone_id: 67 (UTC): an event at 2026-04-01 23:30 UTC lands in the April 1 bucket.timezone_id: 80 (America/New_York): the same UTC timestamp (19:30 EST) also lands in April 1, but an event at 2026-04-02 03:30 UTC (23:30 EST) lands in April 1 under EST and 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.
timezone_id, reports use the network default (reporting_timezone_id on GET /v1/networks/info, same integer ID set as timezone_id). For predictable results, pass it explicitly.
Finding the timezone ID
GET /v1/meta/timezones returns a { "timezones": [...] } list. Each record has four fields:
| Field | Example | Use |
|---|
timezone_id | 67 | Integer ID for request bodies. |
timezone | "UTC" | IANA identifier — key lookups on this field. |
timezone_name | "Greenwich Mean Time (UTC)" | Display string; shifts with DST. Don’t match on it. |
utc_offset | "+00:00" | Currently-effective offset; shifts with DST. |
curl -H "X-Eflow-API-Key: <key>" "https://api.eflow.team/v1/meta/timezones" \
| jq '.timezones[] | select(.timezone == "America/New_York")'
| Timezone | timezone_id |
|---|
| UTC | 67 |
| America/New_York (US Eastern) | 80 |
| America/Chicago (US Central) | 85 |
| America/Denver (US Mountain) | 87 |
| America/Los_Angeles (US Pacific) | 90 |
| America/Sao_Paulo | 72 |
| Europe/London | 63 |
| Europe/Paris | 58 |
| Europe/Berlin | 56 |
| Africa/Johannesburg | 54 |
| Asia/Dubai | 37 |
| Asia/Singapore | 21 |
| Asia/Shanghai | 20 |
| Asia/Tokyo | 16 |
| Australia/Sydney | 12 |
Response timestamps
All response timestamp fields are Unix epoch integers in UTC — regardless of the timezone_id in the request.
{
"time_created": 1709500000,
"conversion_unix_timestamp": 1771455532
}
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:
{
"columns": [{ "column_type": "date", "id": "2026-04-15", "label": "2026-04-15" }],
"reporting": { "total_click": 1200, "cv": 45, "revenue": 4500.00 }
}
date / click_date strings alongside Unix timestamps, in the network’s reporting timezone:
{
"transaction_id": "890c3d5...",
"unix_timestamp": 1715788261,
"date": "2024-05-15 15:53:19",
"click_date": "2024-05-15 15:51:01"
}
/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. 