Decision records · Changes we propose
D-042 Is a commitment's flight start and end a calendar date, as the examples write them, or a point in time?
What we propose
A point in time, a Timestamp, as the offer window's valid_from and valid_until are.
As written
A commitment's flight_start and flight_end are calendar dates, such as 2026-10-06, as the examples write them. The text names no time zone that reads them.
The as-written variant takes the option date. Switch the type map to As written to see it.
Options
Why
The text gives flight_start and flight_end no type, and every example writes a calendar date, such as 2026-10-06. A calendar date names no instant until a time zone reads it (D-038), and no clock the specification has reads a flight: main has none, and the open PRs' time_zone reads only the daypart and the frequency cap's period. So two parties can disagree on when a flight starts. One form for every point in time also lets a receiver compare a flight with the offer window, valid_from and valid_until, which are Timestamps. The schema departs from the examples: a flight starts and ends at a date-time with an offset.
What we ask the specification to change
Write a commitment's flight_start and flight_end as RFC 3339 date-times, as valid_from and valid_until are, such as 2026-10-06T00:00:00-04:00. The examples write calendar dates, which name no instant until a time zone reads them.
The specification lines it rests on
Each line is quoted as the record pins it. Expand an item to read the quote.
main
§ 5.6.1, the
commitment.flight_startkey row L294 at 44dfaafflight_start| REQUIRED | The buyer's campaign start. Distinct fromvalid_from§ 5.6.1, the
commitment.flight_endkey row L295 at 44dfaafflight_end| REQUIRED | The buyer's campaign end. Distinct fromvalid_until
With the open PRs
§ 5.6.1, the
commitment.flight_startkey row L287 on main at 981a74eflight_start| REQUIRED | The buyer's campaign start. Distinct fromvalid_from§ 5.6.1, the
commitment.flight_endkey row L288 on main at 981a74eflight_end| REQUIRED | The buyer's campaign end. Distinct fromvalid_until
Examples that follow the text, not this change
| Example | Where | Why | Input |
|---|---|---|---|
examples/line-item-audio.yaml | /commitment/flight_end | The example follows the text, which gives flight_end no form: it writes the calendar date 2026-12-21. We propose an RFC 3339 date-time for every point in time, such as 2026-12-21T00:00:00-05:00. | main, open PRs |
examples/line-item-audio.yaml | /commitment/flight_start | The example follows the text, which gives flight_start no form: it writes the calendar date 2026-10-06. We propose an RFC 3339 date-time for every point in time, such as 2026-10-06T00:00:00-04:00. | main, open PRs |
examples/line-item-ctv.yaml | /commitment/flight_end | The example follows the text, which gives flight_end no form: it writes the calendar date 2026-12-21. We propose an RFC 3339 date-time for every point in time, such as 2026-12-21T00:00:00-05:00. | main, open PRs |
examples/line-item-ctv.yaml | /commitment/flight_start | The example follows the text, which gives flight_start no form: it writes the calendar date 2026-10-06. We propose an RFC 3339 date-time for every point in time, such as 2026-10-06T00:00:00-04:00. | main, open PRs |
examples/line-item-display.yaml | /commitment/flight_end | The example follows the text, which gives flight_end no form: it writes the calendar date 2026-12-21. We propose an RFC 3339 date-time for every point in time, such as 2026-12-21T00:00:00-05:00. | main, open PRs |
examples/line-item-display.yaml | /commitment/flight_start | The example follows the text, which gives flight_start no form: it writes the calendar date 2026-10-06. We propose an RFC 3339 date-time for every point in time, such as 2026-10-06T00:00:00-04:00. | main, open PRs |
What it shapes
main: Commitment.flight_end, Commitment.flight_start
With the open PRs: Commitment.flight_end, Commitment.flight_start