If you run time-limited promotions, the sale_price_effective_date attribute is the mechanism that tells Google exactly when your sale price should be shown to shoppers. Get the format wrong and the value is silently ignored—or your products accumulate feed errors in Merchant Center. This article covers the exact formatting requirements, time zone behaviour, and the most common mistakes catalog operators make.
What the Attribute Does and When to Use It
The sale_price_effective_date attribute is optional for each product, but it is highly recommended whenever you submit a sale_price. Without it, Google applies your sale price immediately and indefinitely. Google documentation describes the attribute as a way to "tell us how long you want a specific sale price to be shown to users."
The attribute works alongside sale_price, not instead of it. You must submit both attributes together: sale_price carries the discounted price value, and sale_price_effective_date carries the date range during which that price is valid. The Google documentation on sale_price makes this relationship explicit: "To submit the dates of your sale, use the sale price effective date [sale_price_effective_date] attribute."
If you omit sale_price_effective_date entirely, the sale price becomes active as soon as the feed is processed and stays active until you either remove the sale_price value or update the feed. For short, time-sensitive promotions this creates a risk: if your feed update is delayed, shoppers may see a sale price that is no longer valid on your landing page, which can trigger a price mismatch disapproval.
ISO 8601 Format, Character Limits, and Time Zone Rules
This is where most feed errors originate. The attribute has a precise required format and a strict character limit.
Required format
According to Google documentation, the type is a "Date range (use ISO 8601 standard). Submit a start date and an end date with time and timezone of format YYYY-MM-DDThh:mm[±hhmm] or YYYY-MM-DDThh:mmZ , separated by slash ( / )." You must submit a start date and an end date separated by a forward slash (/). Each date must include time and time zone using one of two patterns:
YYYY-MM-DDThh:mm[±hhmm]— explicit UTC offsetYYYY-MM-DDThh:mmZ— UTC
A valid value therefore looks like this:
2024-11-29T09:00-0500/2024-11-29T23:59-0500
For XML feeds the same value is wrapped in a tag:
<g:sale_price_effective_date>2024-11-29T09:00-0500/2024-11-29T23:59-0500</g:sale_price_effective_date>
Character limit
The field accepts 0–51 characters, as stated in the Google documentation: "Limits 0-51 characters". The full pattern YYYY-MM-DDThh:mm±hhmm/YYYY-MM-DDThh:mm±hhmm uses exactly 51 characters including the slash. Any additional whitespace, a trailing zero, or an extra character will push the value over the limit and make it unusable.
Time zone defaults
If you omit the time component, Google defaults the start to 12:00 AM midnight on the start date and the end to 11:59 PM on the end date. If you omit the time zone offset entirely, Google defaults to UTC—as stated in the Google documentation: "If you don't include a timezone, we default to the UTC timezone." For merchants whose store operates in a specific local time zone—US Eastern, Central European, or Australian Eastern, for example—relying on the UTC default means your sale may go live or expire several hours earlier or later than intended. Always include the offset.
Common Feed Errors and How to Fix Them
The Google documentation notes: "Follow the formatting guidelines or the information you submit can't be used." Unlike many other attributes, sale_price_effective_date has no minimum requirements that would cause a product disapproval on its own—but a malformed value means the date range is simply discarded, leaving the sale price active indefinitely or not at all.
Here are the errors catalog operators encounter most often:
1. Missing the time and time zone
Submitting 2024-11-29/2024-11-30 without time or offset is incomplete. The format specification requires hh:mm and a time zone designator. Strip the time out and the value cannot be used.
2. Using a space instead of T as the date-time separator
ISO 8601 requires the letter T between date and time. 2024-11-29 09:00-0500 is invalid. Use 2024-11-29T09:00-0500.
3. Using a colon inside the time zone offset
Some export tools write -05:00 with a colon inside the offset. The format shown in the Google documentation examples uses -0800 without a colon. Colon-separated offsets are not shown in the specification examples and may not be parsed correctly.
4. End date before start date
If your export logic generates the dates incorrectly—for example, by reversing start and end—the date range will be unusable. Always verify that the end timestamp is later than the start timestamp.
5. Exceeding 51 characters
Adding spaces around the slash (2024-11-29T09:00-0500 / 2024-11-29T23:59-0500) adds 2 characters and can push the value past the 51-character limit stated in the Google documentation: "Limits 0-51 characters". Use the slash with no surrounding spaces.
Hypothetical Example: A Black Friday Flash Sale
The following is a hypothetical example for illustration purposes only.
Imagine a store selling apparel in the US Eastern time zone (UTC−5). They want to run a flash sale on a jacket from 6:00 AM to 11:59 PM on 29 November 2024.
Incorrect submission (common mistakes combined):
2024-11-29 06:00 EST / 2024-11-29 23:59 EST
Problems: space instead of T, EST is not a valid ISO 8601 offset designator, and spaces around the slash add characters.
Correct submission for a TSV/CSV feed:
2024-11-29T06:00-0500/2024-11-29T23:59-0500
This value is 45 characters, within the 51-character limit stated by Google documentation, uses the correct T separator, and expresses the time zone as a numeric offset. The full product row would look like:
| Attribute | Value |
|---|---|
id | JACKET-BLK-M |
price | 129.99 USD |
sale_price | 89.99 USD |
sale_price_effective_date | 2024-11-29T06:00-0500/2024-11-29T23:59-0500 |
After the end time passes, the sale_price value in the feed is ignored and the regular price is shown again—provided the feed date range has simply expired.
Variants and Per-SKU Sale Windows
The sale_price_effective_date attribute is not repeated, meaning each product row carries its own single date range value. For item groups with multiple variants—say, a T-shirt in green, blue, and yellow—you can assign a different sale window to each color SKU independently. This is useful when you are running a clearance on slow-moving colorways while keeping other variants at full price.
Each variant row requires its own sale_price, sale_price_effective_date, and item_group_id. Make sure the date ranges you assign to individual variants are accurate; a mismatch between the feed date range and the actual price shown on the landing page can lead to a price mismatch disapproval.
Keeping Your Feed Accurate During Sales
Because sale_price_effective_date is date-driven, Google will stop showing the sale price once the end date passes, even without a feed update. However, if your landing page price changes before the end date—for example, because a promotion was cancelled early—you should update the feed promptly to reflect the current price. A discrepancy between the feed price and the landing page price can trigger a disapproval regardless of what the date range says.
For ongoing catalog management and feed validation across multiple promotions, Magicfeedpro provides tools to manage product data and prepare accurate destination feeds. Keeping date-range attributes correctly formatted at scale—especially across large apparel or electronics catalogs with frequent promotions—is where automated feed management reduces manual error.
Related articles
Product Feed Sale Price Dates: What to Check Before You Go Live
How to validate sale_price and sale_price_effective_date in your product feed before submitting to Google Merchant Center.
excluded_destination Feed Attribute: Accepted Values and Format
Control which Google surfaces show your products using excluded_destination and included_destination feed attributes.
Shipping Attribute in Google Shopping Feeds: Format and Rules
Learn the exact sub-attributes, mandatory conditions, and formatting rules for the shipping attribute in Google Shopping product feeds.