magento/magento2#39169: Special Price To Date is wrongly validated on applySpecialPrice

[KrasnoshchokBohdan]

Description (*)

As the author of the issue mentioned, if we add a special price using POST /rest/<store_code>/V1/products/special-price specifying in the request body date like "price_to": "2017-07-16 23:59:59" i.e. time including hours, minutes and seconds, then as a result we will get that the special price will be valid for one day longer than the specified date

this happens in the method \Magento\Framework\Stdlib\DateTime\Timezone::isScopeDateInInterval where there is code that literally adds +1 day

      if ($dateTo) {
            // fix date YYYY-MM-DD 00:00:00 to YYYY-MM-DD 23:59:59
            $toTimeStamp += 86400;
        }

according to the example from the documentation (where "price_to": "2017-07-16 23:59:59" including hours is specified) we get this execution

therefore in this pull request I propose to skip adding 1 day in case in "price_to" specifies the time including hours

Related Pull Requests

--

Fixed Issues (if relevant)

1. Fixes Special Price To Date is wrongly validated on applySpecialPrice  #39169

Manual testing scenarios (*)

1. add special price to product by POST /rest/<store_code>/V1/products/special-price according documentation
2. check product price, it will have special price one day longer

Questions or comments

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
• All automated tests passed successfully (all builds are green)

[m2-assistant]

Hi @KrasnoshchokBohdan. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[KrasnoshchokBohdan]

@magento run all tests

[engcom-Hotel]

@magento run all tests

[engcom-Hotel]

Hello @KrasnoshchokBohdan,

Thanks for the contribution!

Please fix the failed static test and also please add an automated test in accordance to the DOD.

Thanks

[KrasnoshchokBohdan]

@magento run all tests

[engcom-Hotel]

Hello @KrasnoshchokBohdan,

Please also add some automated tests.

Thanks

[Den4ik]

We will have the same +1 day result if use '00:00:00' in the API query. I'm not sure that it's correct solution

[KrasnoshchokBohdan]

@Den4ik

We will have the same +1 day result if use '00:00:00' in the API query. I'm not sure that it's correct solution

pls provide more information

if we update special price with
"price_to": "2025-07-18 00:00:00" we get "2025-07-18 23:59:59" and this is ok by my view
but if we update with
"price_to": "2025-07-18 17:00:00" we get "2025-07-19 17:00:00" before fix
and "2025-07-18 17:00:00" after

your special price will be visible until tomorrow 17
so instead expire at 2024-09-12 17:00:00 it will expire on 2024-09-13 17:00:00

#39169 from description

how I tested it

https://app.magento.test/rest/default/V1/products/special-price (app.magento.test replace with your base_url)
body
{
"prices": [
{
"price": 100,
"store_id": 0,
"price_from": "2025-04-08 00:00:00",
"price_to": "2025-07-18 17:00:00",
"sku": "test-simple" // your sku
}
]
}
(date price_from should be not in future)

if we check with POST /rest/<store_code>/V1/products/special-price-information
or in catalog_product_entity_datetime price_to date will be the same as in body (for example "2025-07-18 17:00:00")

but we should triger \Magento\Framework\Stdlib\DateTime\Timezone::isScopeDateInInterval
for this I'm using pdp page (with clean cache)

before fix

after fix

[Den4ik]

@KrasnoshchokBohdan I mean +86400 will add 24h to the request date.

"price_to": "2025-07-18 00:00:00" we get "2025-07-18 23:59:59" and this is ok by my view

After the fix "price_to": "2025-07-18 00:00:00" will be "price_to": "2025-07-19 00:00:00"

I haven't checked the source code more deeply, but I don't rule out that somewhere the time value may be thrown off and date become 2025-07-19

[KrasnoshchokBohdan]

After the fix "price_to": "2025-07-18 00:00:00" will be "price_to": "2025-07-19 00:00:00"

but it was the same before fix

fix is only cover

your special price will be visible until tomorrow 17
so instead expire at 2024-09-12 17:00:00 it will expire on 2024-09-13 17:00:00

#39169 from description

{
"prices": [
{
"price": 100,
"store_id": 0,
"price_from": "2025-04-08 00:00:00",
"price_to": "2025-07-18 00:00:00",
"sku": "test-simple"
}
]
}

no changes

after fix

sorry it seems I still don't understand the question

[KrasnoshchokBohdan]

@Den4ik

I haven't checked the source code more deeply, but I don't rule out that somewhere the time value may be thrown off and date become 2025-07-19

maybe you meen - date become 2025-07-17?
because, according to documentations

https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/products/pricing/product-price-special

The special price goes into effect immediately after midnight at the beginning of the start date (00:01) and continues until just before midnight (23:59) on the day before the end date.

and I dont see any manipulation with special price date except the method we looking
\Magento\Catalog\Pricing\Price\SpecialPrice::getValue

so maybe I should replace

// fix date YYYY-MM-DD 00:00:00 to YYYY-MM-DD 23:59:59
            $toTimeStamp += 86400;

to

// fix date YYYY-MM-DD 00:00:00 to YYYY-MM-DD 23:59:59
            $toTimeStamp -= 1;

[KrasnoshchokBohdan]

@magento run Integration Tests

[KrasnoshchokBohdan]

@magento run all tests

[KrasnoshchokBohdan]

@magento run Integration Tests

[engcom-Charlie]

HI @KrasnoshchokBohdan,

Thank you for your contribution!

As I can see that, you are working on the review comments and tests failures, also marked the PR as draft hence I am moving it to on Hold status. Please feel free to Open it once you are done with implementation.

[engcom-Charlie]

It seems that bot moved it to Review bucket, moving it back to On Hold

[KrasnoshchokBohdan]

@magento run all tests

[KrasnoshchokBohdan]

@magento run all tests

[KrasnoshchokBohdan]

@magento run all tests

[KrasnoshchokBohdan]

@magento run all tests

[KrasnoshchokBohdan]

@magento run Functional Tests B2B, Integration Tests, Magento Health Index

[KrasnoshchokBohdan]

@Den4ik @engcom-Hotel
I encountered an issue where tests were breaking in scopes that don’t apply to custom prices, because the method \Magento\Framework\Stdlib\DateTime\Timezone::isScopeDateInInterval is used by several different classes. To address this, I implemented another approach that limits the logic to custom prices only. I’d appreciate your opinion on whether this seems like a good solution or if you see any potential issues.

[engcom-Hotel]

Hello @KrasnoshchokBohdan,

After reviewing the changes in the PR, it appears to offer a reasonable solution to the described issue by limiting the scope to custom prices and addressing the incorrect handling of the time component in specialPriceTo.

However, the duplication of logic (extract the $specialPriceTo adjustment logic into a reusable method or utility class) and the absence of automated tests should be addressed to enhance the robustness of the solution.

@Den4ik, looking forward to your thoughts on this.

Thanks

[engcom-Hotel]

Hello @KrasnoshchokBohdan,

Is this PR is ready for review?