[KonstantinMirin]

Draft. Do not merge until the working group confirms the disposition of #111.

What this changes

A daypart now has a clock and a shape. time_zone (§ 5.5), seller-set, is an IANA time zone name or viewer_local (where the ad renders). It is the clock for daypart and frequency_cap.period, REQUIRED with either. A daypart window is { days[], start, end }: days from Monday to Sunday, HH:MM civil time, and an exclusive end later than start, up to 24:00. A window that crosses midnight is two windows. A skipped daylight-saving hour matches no instant, and a repeated hour matches both. frequency_cap.period is a calendar period in time_zone; weeks start on Monday.

Ad servers disagree on whose clock applies. Google Ad Manager DayPartTargeting defaults to the viewer, Campaign Manager 360 DayPartTargeting to New York, and Display & Video 360 has no default. So 06:00–10:00 on a national line item means different hours on each platform. UTC or a fixed offset drifts an hour at each daylight-saving change; a zone name doesn't.

Related issue

Refs #111, from @dineshbhat, and #58, from @dtbarne. The text is § 5.5 as proposed in our reply on typed geo codes (#58) and its supporting material, clock and window only. Device types, geo, containment, exclusion, and frequency_cap.basis stay with #58, the device half of #111, and PR #72.

Our reply on #111 explains two differences:

• One clock per line item. [Change] § 5.5 — Type the device and daypart envelopes: AdCOM device types, and dayparts with a time-zone basis #111 puts tz_basis and tz on each window. Here time_zone is set once, because frequency_cap.period needs the daypart's clock.
• Midnight. [Change] § 5.5 — Type the device and daypart envelopes: AdCOM device types, and dayparts with a time-zone basis #111 allows end earlier than start. Here end is later, as in Google Ad Manager DayPart and Google Ads AdScheduleInfo, so a validator catches swapped times.

@dineshbhat, does one clock per line item work for your planning use?

Type

• Editorial — no normative effect
• Normative — changes what the spec requires
• Breaking — would break an implementation already built to this draft
• Examples / schema / docs only

Checklist

• The body section is updated — § 5.5
• Appendix A (field index) matches the body — one row, time_zone seller-set; scripts/check_appendix.py passes
• Appendix B (fields by marker, and the counts) matches the body — seller-set 29 → 30; 71 → 72 fields
• Any affected example in examples/ is updated and still parses — display gains time_zone: "America/New_York", CTV and audio viewer_local
• RFC 2119 keywords used deliberately — MUST / SHOULD / MAY are not synonyms
• The no-inheritance rule (§ 2) still holds — time_zone is per line item
• Anything selectable declares available[] and included[]; anything settable declares bounds (§ 3.1, § 3.2) — daypart keeps allowed[]
• No confidential or commercially sensitive content

Knock-on effects

• Other PRs. PRs § 5.5 — Buyer-supplied block lists (#25) #71 and § 5.5 — Selectable geo with per-market price deltas (#14) #72 also edit the § 5.5 lead sentence; a merge keeps both. Examples from PRs § 2, § 4.1, § 5.6 — Line-item dependencies and bonus lines (#23) #70 and § 2.1, § 5.2 — Placement: what each impression is (#89) #120 carry frequency_cap.period and need time_zone: viewer_local.

For the working group

Open on #58, its supporting material, and #111:

1. Should time_zone take only an IANA name or viewer_local, or also an inventory_local token, or be settable so the buyer picks the clock? ([Change] § 5.5 — Typed geo codes aligned with the OpenRTB 2.6 Geo object #58 reply, question 1)
2. Should period count calendar periods, as OpenDirect 2.1 Line.frequencyinterval does, or rolling windows? ([Change] § 5.5 — Typed geo codes aligned with the OpenRTB 2.6 Geo object #58 reply, question 2)
3. Should weeks start on Monday, or should the seller declare the week start, since Microsoft Invest starts weeks on Sunday? (supporting material, question 3)
4. On a fall-back day, should a window match both occurrences of the repeated hour, or only the first? (supporting material, question 4)
5. Should #37 state that start and end are civil times outside its UTC rule, or should § 5.5 Targeting envelope alone carry that exception? (supporting material, question 5)
6. Linear TV books by broadcast day, often from 06:00. If linear comes into scope, should § 5.5 add a broadcast-day option, or keep two civil-time windows? ([Change] § 5.5 — Type the device and daypart envelopes: AdCOM device types, and dayparts with a time-zone basis #111 reply, question 1)

---

By opening this pull request I agree my contribution may be published under this
repository's licence, as set out in CONTRIBUTING.md.

Revised 2026-10-26: The daypart row lists the day names once, as one value list. HH:MM and UTC are plain text, since they are a format and an example. The meaning is unchanged.

Analyzed and generated with the help of Claude, fully reviewed by me.