[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.

[KonstantinMirin]

Postindustria (IAB Tech Lab member). The IANA zone names in this PR could give IAB specifications one form for time zones. Earlier specifications have no shared form:

Specification	Field	Form
OpenDirect 2.1	Product.tz	Free text, such as "Eastern Standard Time" or "GMT"
OpenDirect 2.1 OOH targeting	OOH timezone target	Local or UTC, default Local
AdCOM 1.0	Geo.utcoffset	Minutes from UTC
Deal Sync API 1.0	startdate, enddate	UTC, ISO 8601
LEAP Forecast API	scheduledstart, scheduledend	Unix milliseconds

LEAP's and Deal Sync's timestamps each name one instant, so they suit a flight's start and end (@VJAlkimi's UTC rule (#37), our reply on flight dates (#127)). A daypart repeats across daylight-saving changes, so UTC or a fixed offset can't state it. A zone name can.

OpenDirect's OOH values map directly: Local is viewer_local, and UTC is an IANA name. We'd suggest the same names for OpenDirect's tz, and an optional zone name beside AdCOM's utcoffset.

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

[KonstantinMirin]

Postindustria (IAB Tech Lab member). Our buyer writes PR carries this PR's text:

• daypart becomes Settable[ClockWindow], and a window's end becomes before.
• time_zone is a ZoneName: an IANA zone or viewer_local. It's REQUIRED when daypart or frequency_cap is present, and it's the clock for a calendar frequency_cap.period.

It also adds what this PR left to our reply on #58: device.allowed[] as AdCOM codes, and Narrowing[T] with include[] and exclude[].

We'll close this PR once the task force reviews that one.

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