Campaign Timezone Converter

Runs in your browser · nothing sent, stored, or logged

A flight date is a wall-clock time, not an instant

This is the distinction that causes campaigns to end early or run long. When an insertion order says a flight ends 30 June, it means midnight at the end of 30 June in some timezone — and which timezone is a property of the platform, not of the date. Midnight on 30 June in Sydney has already passed by the time it arrives in Los Angeles, seventeen hours later. If a client in one market books a campaign that a platform schedules in another, the flight can start or finish a day off what everyone expected, and the delivery report will look like a pacing failure rather than a scheduling one.

Reporting timezone is the other half of the problem

Every platform closes its reporting day at midnight in whatever zone it is configured for, and those configurations rarely match across a stack. A DSP reporting in UTC and an ad server reporting in the network's local time will disagree on every single day of a flight while agreeing on the total, because the boundary between days falls in a different place. Before investigating a daily discrepancy, check the reporting timezone on both systems — it explains more mismatches than any counting difference does.

Frequently asked questions

Is my timestamp in seconds or milliseconds?

The converter detects it from the magnitude, because platforms are inconsistent and the failure is silent. A ten-digit number is seconds; a thirteen-digit one is milliseconds. Reading milliseconds as seconds pushes a 2026 date into the year 57000, which is obvious — reading seconds as milliseconds gives 1970, which people sometimes accept as a real answer.

Why did my campaign end a day early?

Because a flight end date is a wall-clock time in the platform's timezone, not an instant. "Ends 30 June" means midnight in whichever zone the platform is set to, and that is a different moment depending on the zone — up to a full day apart between Sydney and Los Angeles. Check which timezone the campaign was booked in before assuming under-delivery.

Why do my DSP and ad server report different daily numbers?

Usually because they close the day at different moments. If one reports in UTC and the other in the network's local timezone, every daily figure is shifted by the offset between them, so the totals reconcile over a flight but no single day matches. Compare on a full-flight basis, or set both to the same reporting timezone.

Does daylight saving affect campaign delivery?

It affects the boundaries. On the day a zone changes, one day contains 23 or 25 hours, so a daily budget cap covers a slightly different amount of delivery than usual. It rarely matters on a month-long flight and can matter a great deal on a one-day burst timed around an event.