TAP delivers a flight according to each station’s local time zone. To handle all time zones globally, Triton waits 2 days in the UTC +0 time zone before setting the flight’s status to Done. This lets Triton still deliver impressions in time zones where the local End date and End time have not passed. This 2-day wait also affects reporting.
Example
For example, a flight targets stations in these time zones:
Eastern Standard Time (UTC -5)
Central European Time (UTC +1)
The flight’s End date and End time are December 1, 23:59.
At End date in the UTC +0 time zone, Triton starts applying the 2-day wait at midnight, which is December 1, 00:00 (UTC +0).
During these 2 days, Triton stops delivering impressions at the station’s local time zone:
Station time zone | Local End Date and End time | UTC +0 End date and End time |
|---|---|---|
Central European Time (UTC +1) | December 1, 23:59 | December 1, 22:59 |
Eastern Standard Time (UTC -5) | December 1, 23:59 | December 2, 04:59 |
At December 3, 23:59 (UTC +0), Triton sets the flight’s status to Done.
Expired Flights and Reporting
Keep this in mind that Triton accounts for timezone differences by keeping the flight status as Active for a 48-hour buffer on either side of the flight's date range. The flight isn't necessarily delivering during these buffer zones, but it is active despite the fact that these times appear to be outside of the set date range.
Without this 2-day wait, running reports would be confusing because reporting is set to universal time (UTC). So if you run a report for stations in the UTC -5 and UTC +1 time zones, you would not only need to account for the UTC time zone difference, you would also need to account for the fact that the impressions ran for more than the 24 hours defined in the flight's date range.