The short answer
A sale interval has different jobs in different feed contracts. Google Merchant Center uses sale_price_effective_date to set the sale-price display period. OpenAI Stable native uploads need current price updates; its separately confirmed Google-compatible profile accepts that interval as metadata without scheduling activation. Choose the destination first, then review the current offer and the next required change.
The same field name does not carry the same scheduling contract
Confirm the actual destination and upload profile before reusing a promotion export. A Google Merchant Center feed and an OpenAI feed using Google-compatible column names are separate contracts. OpenAI requires confirmation of the compatible format for the registered feed.
The Stable native field table does not document sale_price_effective_date as a native field. Do not infer whether an unknown field is accepted, ignored, or rejected from that absence.
| Destination | What the date does | What the reviewer must establish |
|---|---|---|
| Google Merchant Center | sale_price_effective_date defines a sale-price display interval. | Keep the intended interval and reconcile the matching offer. |
| OpenAI Stable native upload | Uploaded sale dates do not schedule price changes. | Supply the current sale_price and update it when the sale begins or ends. |
| OpenAI confirmed Google-compatible upload | sale_price_effective_date is accepted date metadata, not sale activation. | Confirm this profile; supply current sale state. The date requires sale_price and start before end. |
Source: Google Merchant Center: sale price effective date; OpenAI Stable file-upload products specification
Preserve the raw interval and its timezone
Google recommends explicit times and timezones. Its documented fallback is UTC when timezone is omitted; without times, the interval covers the named start and end days. OpenAI’s compatible field permits dates or zoned timestamps and defines date-only boundaries by UTC days.
Our review policy holds a business schedule whose intended timezone is unknown, even when a provider has a documented default. That hold protects the intended promotion; it is not a claim that the provider rejects the value. Keep the raw string alongside the owner-confirmed interpretation.
The cases below stay away from exact start and end instants. They make no claim about boundary inclusivity, processing deadlines, or the moment a user will see a changed price.
Source: Google Merchant Center: sale price effective date; OpenAI Stable file-upload products specification
One future promotion can require different exports
Consider a fictional blue mug with a USD 100 regular price and a planned USD 80 sale, from October 5 at 09:00 to October 7 at 18:00 with an explicit -0400 offset. At the frozen October 2 observation, its current item price is still USD 100.
For Google Merchant Center, the reviewer can retain the planned sale amount and its future display interval. For the two OpenAI profiles in this guide, the review instead prepares current-price data and preserves the future plan internally. The confirmed compatibility date is not a substitute for a current-price update; removing its premature sale value also calls for omitting the dependent date field.
These are proposed mapping decisions for supplied fictional evidence. They do not submit a feed, confirm processing, or observe a destination. When the sale actually begins or ends, capture fresh evidence before preparing the corresponding current-state update.
Source: Google Merchant Center: sale price effective date; OpenAI Stable file-upload products specification
Eight cases for a human review
The JSON download contains eight fictional manual review cases, with a selected destination, raw interval, explicit timezone or recorded absence, frozen asOf, evidence references, current-sale state, and expected editorial action. The labels describe review work; no validator runs these cases and no expected provider response is supplied.
Native cases store the raw interval in the internal promotion plan. They do not advertise it as a supported native feed field. The reversed-interval and missing-business-timezone cases use a stated author hold policy, rather than predicting upload rejection.
| Case | Profile | Question | Expected editorial action |
|---|---|---|---|
| SW1 | Future interval; current offer regular | Retain schedule and verify offer | |
| SW2 | Observed active sale inside interval | Reconcile active offer | |
| SW3 | OpenAI native | Future sale value supplied early | Prepare removal of premature sale |
| SW4 | OpenAI native | Observed sale; sale value missing | Prepare current sale update |
| SW5 | OpenAI native | Observed end; sale value remains | Prepare removal of ended sale |
| SW6 | OpenAI compatible, confirmed | Future date treated as an activation schedule | Prepare omission of premature sale and dependent date |
| SW7 | OpenAI compatible, confirmed | Reversed interval | Hold and resolve date plan |
| SW8 | Intended business timezone unknown | Hold and confirm timezone |
Keep the plan, current offer, and release evidence separate
Start a review with the destination profile and exact item, market, and currency. Preserve the raw date and its confirmed interpretation. Record current-sale evidence at an explicit reference time, then name the proposed field change or unresolved question.
The reusable record includes a blank form and a filled fictional SW6 example. Null means unresolved or unrecorded in this internal format. A proposed omission is described explicitly; the worksheet is not a feed payload or an input accepted by the existing product-record or freshness checker.
- Document confirmation before selecting OpenAI’s Google-compatible profile.
- Keep a promotion plan distinct from evidence that the current offer is on sale.
- Hold reversed intervals, unresolved source conflicts, or missing current-sale evidence under this author review policy.
- Retain any authorized upload receipt and observed destination result separately from the preparation decision.
Check present agreement after choosing the contract
This guide resolves whether a date performs scheduling work. The existing freshness checker compares supplied current snapshots; it does not evaluate sale intervals or activate promotions. After establishing the current price for the selected contract, use that comparison for its documented scope.
Retain the preparation decision, any upload receipt, and the observed destination price as separate records. Verify the current offer after a released change and keep that observation attached to the promotion plan.
Sources & scope
Primary references checked for this edition. The notes below distinguish source-backed facts from the frameworks and examples proposed in this guide.
- Google Merchant Center: sale price effective date ↗
Defines the interval controlling sale-price display, date/time formatting, and UTC/default whole-day behavior. It does not establish exact processing times or a live display result.
Checked October 17, 2026 - OpenAI Stable file-upload products specification ↗
Separates native current-price updates from the confirmed Google-compatible date-metadata field. The compatibility path must be confirmed for the registered feed; its scheduling behavior differs from Google Merchant Center.
Checked October 17, 2026
AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.
Editorial policy & corrections ↗Cite this guide
George Kelly. Sale price effective dates: do they schedule the promotion? iamgeorgekelly. Updated October 17, 2026. https://www.iamgeorgekelly.com/field-guide/sale-price-effective-date-behavior
Keep the source notes and example labels with an excerpt. For a provider requirement, follow the original documentation in Sources & scope.