LinkedIn Marketing API UTC-only aggregation in reporting

Direct Answer

No, the LinkedIn Marketing API v2 does not provide any documented method, query parameter, header, or account-level setting to shift daily aggregation windows away from UTC. All reporting endpoints (adAnalyticsV2, campaignAnalytics, creativeAnalytics, etc.) interpret startDate and endDate as UTC midnight boundaries and return timestamps exclusively in UTC ISO 8601 format. The IANA timezone identifier available via the r_liteprofile scope is not propagated to analytics or campaign-management endpoints.

Why This Exists (Likely Explanation)

LinkedIn's backend stores impression and click events with UTC timestamps and pre-aggregates them into UTC-day partitions for performance. Adding per-advertiser timezone partitions would multiply storage requirements and complicate cross-timezone reporting consistency. This architectural choice is unlikely to change in the current API version.

Client-Side Re-aggregation Pattern

To align metrics with an advertiser's local campaign day (including DST transitions), implement the following steps:

1. Determine the operational timezone. Retrieve the account's timezone from the Accounts API (GET /rest/adAccountsV2). Note: this field may return a Windows zone ID (e.g., "Pacific Standard Time") rather than IANA; map it to IANA via CLDR or a maintained lookup table before using timezone libraries.
2. Fetch an extended UTC window. For each desired local date range, pull raw UTC-day metrics covering localStart - 1 day through localEnd + 1 day in UTC. This ensures all events that fall into the local days are captured, since a single local date can map to 23 or 25 UTC hours during DST transitions.
3. Re-aggregate using IANA zone rules per date. Use a timezone-aware library (java.time, date-fns-tz, pytz, zoneinfo) that applies historical DST rules for the specific IANA zone. Do not use a fixed offset. For each event timestamp, convert to the local zone and bucket by local date.
4. Cache results keyed by (accountId, localDate, timezoneVersion). The timezone version (e.g., tzdata release) matters because governments change DST rules. If the account's timezone setting changes mid-campaign, historical re-aggregation must use the zone that was in effect on each local date, not the current setting.

Verification Steps

• Call GET /rest/adAnalyticsV2?q=analytics&pivot=DAY&dateRange.start.day=1&dateRange.start.month=1&dateRange.start.year=2026&dateRange.end.day=2&dateRange.end.month=1&dateRange.end.year=2026&timeGranularity=DAILY and confirm returned dateRange values are UTC midnight timestamps.
• Inspect the Accounts API response for a known account and note the timezone field format (IANA vs Windows).
• Run a local re-aggregation for a DST transition date (e.g., 2026-03-08 America/New_York) and verify the 23-hour local day maps to two UTC days (2026-03-08 and 2026-03-09).
• Cross-check one campaign's spend total in the re-aggregated local-day table against the Campaign Manager UI for the same local date; they should match within rounding differences.

Operational Cautions

• Rate limits on analytics endpoints are strict; fetching the extended UTC window for every local-day query can exhaust quota. Consider daily ETL jobs that materialize local-day tables.
• Creative-level and conversion-rule breakdowns may not sum exactly to campaign totals due to attribution windows; re-aggregate at the finest granularity available to reduce drift.
• If the advertiser changes their account timezone in Campaign Manager, your pipeline must detect this and reprocess affected historical dates using the new zone rules from the change date forward.

One Diagnostic Detail Needed

What is the exact timezone value returned by the Accounts API for your target account(s)—IANA (e.g., "America/Los_Angeles") or Windows (e.g., "Pacific Standard Time")? This determines whether you need a Windows-to-IANA mapping step and which library APIs to call.