> ## Documentation Index
> Fetch the complete documentation index at: https://developers.everflow.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Timezones
> How the Everflow API handles timezones in reporting requests, response timestamps, and webhook payloads.
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.
```json theme={null}
{
"from": "2026-04-01",
"to": "2026-04-30",
"timezone_id": 67,
"columns": [{ "column": "date" }]
}
```
Event at `2026-04-01 23:30 UTC` → **April 1** bucket.
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`.
| Timezone | `timezone_id` | UTC offset |
| ------------------------------- | ------------- | ---------- |
| Pacific/Kiritimati | `1` | UTC+14:00 |
| Pacific/Enderbury | `2` | UTC+13:00 |
| Pacific/Tongatapu | `3` | UTC+13:00 |
| Pacific/Chatham | `4` | UTC+12:45 |
| Pacific/Auckland | `5` | UTC+12:00 |
| Pacific/Fiji | `6` | UTC+12:00 |
| Asia/Kamchatka | `7` | UTC+12:00 |
| Pacific/Norfolk | `8` | UTC+11:30 |
| Australia/Lord\_Howe | `9` | UTC+11:00 |
| Pacific/Guadalcanal | `10` | UTC+11:00 |
| Australia/Adelaide | `11` | UTC+10:30 |
| Australia/Sydney | `12` | UTC+10:00 |
| Australia/Brisbane | `13` | UTC+10:00 |
| Australia/Darwin | `14` | UTC+09:30 |
| Asia/Seoul | `15` | UTC+09:00 |
| Asia/Tokyo | `16` | UTC+09:00 |
| Asia/Hong\_Kong | `17` | UTC+08:00 |
| Asia/Kuala\_Lumpur | `18` | UTC+08:00 |
| Asia/Manila | `19` | UTC+08:00 |
| Asia/Shanghai | `20` | UTC+08:00 |
| Asia/Singapore | `21` | UTC+08:00 |
| Asia/Taipei | `22` | UTC+08:00 |
| Australia/Perth | `23` | UTC+08:00 |
| Asia/Bangkok | `24` | UTC+07:00 |
| Asia/Ho\_Chi\_Minh | `25` | UTC+07:00 |
| Asia/Jakarta | `26` | UTC+07:00 |
| Asia/Rangoon | `27` | UTC+06:30 |
| Asia/Dhaka | `28` | UTC+06:00 |
| Asia/Kathmandu | `29` | UTC+05:45 |
| Asia/Colombo | `30` | UTC+05:30 |
| Asia/Kolkata | `31` | UTC+05:30 |
| Asia/Karachi | `32` | UTC+05:00 |
| Asia/Tashkent | `33` | UTC+05:00 |
| Asia/Yekaterinburg | `34` | UTC+05:00 |
| Asia/Kabul | `35` | UTC+04:30 |
| Asia/Baku | `36` | UTC+04:00 |
| Asia/Dubai | `37` | UTC+04:00 |
| Asia/Tbilisi | `38` | UTC+04:00 |
| Asia/Yerevan | `39` | UTC+04:00 |
| Asia/Tehran | `40` | UTC+03:30 |
| Africa/Nairobi | `41` | UTC+03:00 |
| Asia/Baghdad | `42` | UTC+03:00 |
| Asia/Kuwait | `43` | UTC+03:00 |
| Asia/Riyadh | `44` | UTC+03:00 |
| Europe/Minsk | `45` | UTC+03:00 |
| Europe/Moscow | `46` | UTC+03:00 |
| Africa/Cairo | `47` | UTC+03:00 |
| Asia/Beirut | `48` | UTC+03:00 |
| Asia/Jerusalem | `49` | UTC+03:00 |
| Europe/Athens | `50` | UTC+03:00 |
| Europe/Bucharest | `51` | UTC+03:00 |
| Europe/Helsinki | `52` | UTC+03:00 |
| Europe/Istanbul | `53` | UTC+03:00 |
| Africa/Johannesburg | `54` | UTC+02:00 |
| Europe/Amsterdam | `55` | UTC+02:00 |
| Europe/Berlin | `56` | UTC+02:00 |
| Europe/Brussels | `57` | UTC+02:00 |
| Europe/Paris | `58` | UTC+02:00 |
| Europe/Prague | `59` | UTC+02:00 |
| Europe/Rome | `60` | UTC+02:00 |
| Europe/Lisbon | `61` | UTC+01:00 |
| Africa/Algiers | `62` | UTC+01:00 |
| Europe/London | `63` | UTC+01:00 |
| Atlantic/Cape\_Verde | `64` | UTC-01:00 |
| Africa/Casablanca | `65` | UTC+00:00 |
| Europe/Dublin | `66` | UTC+00:00 |
| UTC | `67` | UTC+00:00 |
| America/Scoresbysund | `68` | UTC+00:00 |
| Atlantic/Azores | `69` | UTC+00:00 |
| Atlantic/South\_Georgia | `70` | UTC-02:00 |
| America/St\_Johns | `71` | UTC-02:30 |
| America/Sao\_Paulo | `72` | UTC-03:00 |
| America/Argentina/Buenos\_Aires | `73` | UTC-03:00 |
| America/Santiago | `74` | UTC-03:00 |
| America/Halifax | `75` | UTC-03:00 |
| America/Puerto\_Rico | `76` | UTC-04:00 |
| Atlantic/Bermuda | `77` | UTC-04:00 |
| America/Caracas | `78` | UTC-04:30 |
| America/Indiana/Indianapolis | `79` | UTC-04:00 |
| America/New\_York | `80` | UTC-04:00 |
| America/Bogota | `81` | UTC-05:00 |
| America/Lima | `82` | UTC-05:00 |
| America/Panama | `83` | UTC-05:00 |
| America/Mexico\_City | `84` | UTC-05:00 |
| America/Chicago | `85` | UTC-05:00 |
| America/El\_Salvador | `86` | UTC-06:00 |
| America/Denver | `87` | UTC-06:00 |
| America/Mazatlan | `88` | UTC-06:00 |
| America/Phoenix | `89` | UTC-07:00 |
| America/Los\_Angeles | `90` | UTC-07:00 |
| America/Tijuana | `91` | UTC-07:00 |
| Pacific/Pitcairn | `92` | UTC-08:00 |
| America/Anchorage | `93` | UTC-08:00 |
| Pacific/Gambier | `94` | UTC-09:00 |
| America/Adak | `95` | UTC-09:00 |
| Pacific/Marquesas | `96` | UTC-09:30 |
| Pacific/Honolulu | `97` | UTC-10:00 |
| Pacific/Niue | `98` | UTC-11:00 |
| Pacific/Pago\_Pago | `99` | UTC-11:00 |
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.
```bash theme={null}
curl -H "X-Eflow-API-Key: " "https://api.eflow.team/v1/meta/timezones" \
| jq '.timezones[] | select(.timezone == "America/New_York")'
```
## Response timestamps
All response timestamp fields are **Unix epoch integers in UTC** — regardless of the `timezone_id` in the request.
```json theme={null}
{
"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`:
```json theme={null}
{
"columns": [{ "column_type": "date", "id": "2026-04-15", "label": "2026-04-15" }],
"reporting": { "total_click": 1200, "cv": 45, "revenue": 4500.00 }
}
```
**2. Firehose stream** — top-level `date` / `click_date` strings alongside Unix timestamps, in the **network's reporting timezone**:
```json theme={null}
{
"transaction_id": "890c3d5...",
"unix_timestamp": 1715788261,
"date": "2024-05-15 15:53:19",
"click_date": "2024-05-15 15:51:01"
}
```
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.