D-038 In which time zone are a line item's calendar values read, its daypart windows, its frequency cap's period, and the days of its flight?

What the schemas do

One clock per line item reads its daypart windows and its frequency cap's period, as the time_zone of #123 does. The schemas add no such field until the text has it. A Timestamp, a flight's start and end included, stays an RFC 3339 instant with an offset, which needs no clock.

Options

• line-item-time-zone Chosen

  One clock per line item reads its daypart windows and its frequency cap's period, as the time_zone of #123 does. The schemas add no such field until the text has it. A Timestamp, a flight's start and end included, stays an RFC 3339 instant with an offset, which needs no clock.

• zone-suffix

  Each Timestamp carries its zone as an RFC 9557 suffix, such as 2026-10-06T00:00:00-04:00[America/New_York].

• per-window

  Each daypart window names its own time zone.

Why

A daypart window and a frequency cap's period are calendar values: a window is a time of day and a period resets at a calendar boundary (D-044), and both move with daylight saving time, which an offset doesn't record. Ad servers read them in one time zone per line item, and an IANA name records daylight saving time where an offset doesn't. RFC 9557 suffixes put a zone on each value, which lets two values of one line item disagree, and few JSON Schema validators check them. A zone per daypart window has the same defect. On main the specification has no time_zone field, so the schema adds none. The open PR that adds time_zone makes it the clock for the daypart and the frequency cap's period only, with viewer_local beside the IANA names, and with it the schema types the field from the text. Neither text says which clock reads a flight: the examples write flight_start and flight_end as calendar dates, which name no instant until a zone reads them, and the schema writes them as Timestamps (D-042), which need none. So the flight's clock stays open on both locks.

What we ask the specification to state

Adopt the line item time_zone that #123 adds, an IANA zone name or viewer_local, as the clock for daypart and frequency_cap.period. One clock is still open. The examples write flight_start and flight_end as calendar dates. Say which zone reads their days, or write them as RFC 3339 date-times with an offset, which need no zone.

The specification lines it rests on

Each line is quoted as the record pins it. Expand an item to read the quote.

main

• § 5.5, the daypart row L260 at 44dfaaf

  daypart | Object | settable | allowed[] of time windows

• § 5.5, the frequency_cap row L261 at 44dfaaf

  frequency_cap | Object | settable | { max: { min, max }, period, basis: device | household | listener }. Basis matters: CTV typically caps at household, audio at listener

• § 5.6.1, the commitment.flight_start key row L294 at 44dfaaf

  flight_start | REQUIRED | The buyer's campaign start. Distinct from valid_from

• § 5.6.1, the commitment.flight_end key row L295 at 44dfaaf

  flight_end | REQUIRED | The buyer's campaign end. Distinct from valid_until

With the open PRs

• § 5.6.1, the commitment.flight_start key row L287 on main at 981a74e

  flight_start | REQUIRED | The buyer's campaign start. Distinct from valid_from

• § 5.6.1, the commitment.flight_end key row L288 on main at 981a74e

  flight_end | REQUIRED | The buyer's campaign end. Distinct from valid_until

What it shapes

main: DaypartWindow, Commitment.flight_end, Commitment.flight_start, LineItem.daypart, LineItem.frequency_cap