Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 36 commits into
base: 2.4-develop
Choose a base branch
from

Conversation

KrasnoshchokBohdan
Copy link
Contributor

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
Screenshot 2025-03-01 at 12 35 20

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)

Copy link

m2-assistant bot commented Mar 1, 2025

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.

@m2-github-services m2-github-services added Partner: Perspective partners-contribution Pull Request is created by Magento Partner labels Mar 1, 2025
@KrasnoshchokBohdan
Copy link
Contributor Author

@magento run all tests

@engcom-Bravo engcom-Bravo added the Priority: P3 May be fixed according to the position in the backlog. label Mar 3, 2025
@Priyakshic Priyakshic added the Project: Community Picked PRs upvoted by the community label Mar 13, 2025
@Priyakshic Priyakshic moved this to Pending Review in Community Dashboard Mar 13, 2025
@engcom-Hotel engcom-Hotel self-requested a review March 28, 2025 05:00
@engcom-Hotel
Copy link
Contributor

@magento run all tests

@engcom-Hotel engcom-Hotel moved this from Pending Review to Review in Progress in Community Dashboard Mar 28, 2025
Copy link
Contributor

@engcom-Hotel engcom-Hotel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@engcom-Hotel engcom-Hotel moved this from Review in Progress to Changes Requested in Community Dashboard Apr 1, 2025
@engcom-Charlie engcom-Charlie self-assigned this Apr 1, 2025
@KrasnoshchokBohdan
Copy link
Contributor Author

@magento run all tests

Copy link
Contributor

@engcom-Hotel engcom-Hotel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @KrasnoshchokBohdan,

Please also add some automated tests.

Thanks

@@ -274,7 +274,7 @@ public function isScopeDateInInterval($scope, $dateFrom = null, $dateTo = null)
$scopeTimeStamp = $this->scopeTimeStamp($scope);
$fromTimeStamp = strtotime($dateFrom);
$toTimeStamp = strtotime($dateTo);
if ($dateTo) {
if ($dateTo && date('H:i:s', strtotime($dateTo)) === '00:00:00') {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

@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
image

after fix
image

@Den4ik
Copy link
Contributor

Den4ik commented Apr 9, 2025

@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
Copy link
Contributor Author

KrasnoshchokBohdan commented Apr 9, 2025

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
image

after fix
image

sorry it seems I still don't understand the question

@KrasnoshchokBohdan
Copy link
Contributor Author

@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
image

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;
image

@ct-prd-projects-boards-automation ct-prd-projects-boards-automation bot moved this from Review in Progress to Ready for Testing in Community Dashboard Jun 2, 2025
@engcom-Bravo engcom-Bravo self-assigned this Jun 3, 2025
@engcom-Bravo engcom-Bravo moved this from Ready for Testing to Testing in Progress in Community Dashboard Jun 3, 2025
@engcom-Bravo
Copy link
Contributor

Hi @KrasnoshchokBohdan,

Thanks for your Contribution!!.

We have tried to reproduce the issue in Latest 2.4-develop instance and we are able to reproduce the issue but after taking PR changes we are not able to access the Category and Products.

Screenshot 2025-06-03 at 3 18 02 pm Screenshot 2025-06-03 at 3 16 06 pm

Could you please recheck and kindly let us know if we are missing anything.

Thanks.

@engcom-Bravo engcom-Bravo moved this from Testing in Progress to Changes Requested in Community Dashboard Jun 3, 2025
@KrasnoshchokBohdan
Copy link
Contributor Author

@engcom-Hotel Hi, I can't reproduce this issue in my local environment, but according to the screenshot, I assume that the problem is related to changes in \Magento\Catalog\Pricing\Price\SpecialPrice::PRICE_CODE. Therefore, I have rolled back those changes. (I previously changed this constant due to an error in static tests.)

@KrasnoshchokBohdan
Copy link
Contributor Author

@magento run all tests

Copy link
Contributor

@engcom-Hotel engcom-Hotel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @KrasnoshchokBohdan,

It seems you have fixed the mentioned issue by @engcom-Bravo, but we can see some static tests are failing.

Please fix those as well.

Thanks

@KrasnoshchokBohdan
Copy link
Contributor Author

@magento run Static Tests

@KrasnoshchokBohdan
Copy link
Contributor Author

@magento run Database Compare, Functional Tests B2B, Functional Tests CE, Functional Tests EE, Integration Tests, Magento Health Index, Sample Data Tests B2B, Sample Data Tests CE, Sample Data Tests EE, Semantic Version Checker, Unit Tests, WebAPI Tests

@ct-prd-projects-boards-automation ct-prd-projects-boards-automation bot moved this from Review in Progress to Ready for Testing in Community Dashboard Jun 5, 2025
@engcom-Bravo engcom-Bravo moved this from Ready for Testing to Testing in Progress in Community Dashboard Jun 6, 2025
@engcom-Bravo
Copy link
Contributor

Hi @KrasnoshchokBohdan,

Thanks for the collaboration & contribution!

✔️ QA Passed

Preconditions:

  • Install fresh Magento 2.4-develop

Steps to reproduce

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

Before: ✖️ 

Screenshot 2025-06-03 at 2 58 15 pm Screenshot 2025-06-03 at 2 58 26 pm

After: ✔️

After time got expired special price was removed.

Screenshot 2025-06-06 at 2 32 13 pm Screenshot 2025-06-06 at 2 32 26 pm

Builds are failed. Hence, moving this PR to Extended Testing.

Thanks.

@engcom-Bravo engcom-Bravo moved this from Testing in Progress to Extended testing (optional) in Community Dashboard Jun 6, 2025
@engcom-Dash engcom-Dash self-assigned this Jun 9, 2025
@engcom-Dash
Copy link
Contributor

@magento run all tests

@engcom-Dash
Copy link
Contributor

@magento run Functional Tests B2B, Functional Tests CE, Functional Tests EE

@engcom-Dash
Copy link
Contributor

The consistent test failures for Functional B2B are known Issues and JIRA is raised for them. Other failures are inconsistent and seems to be flaky. They neither part of PR nor failing because of the PR changes.

Build 1: https://public-results-storage-prod.magento-testing-service.engineering/reports/magento/magento2/pull/39690/8f42d3566719b9958325376679173f3c/Functional/allure-report-b2b/index.html#categories/8fb3a91ba5aaf9de24cc8a92edc82b5d

image

Build 2: https://public-results-storage-prod.magento-testing-service.engineering/reports/magento/magento2/pull/39690/287a336c87e5d0b284d3f8d478a1f240/Functional/allure-report-b2b/index.html#categories/8fb3a91ba5aaf9de24cc8a92edc82b5d

image

Known Issues:
OrderWithMultipleConfigurableProductsAdditionalStockTest : ACQE-8060
EnablePaypalExpressCheckoutAndSubmitAnOrderUsingPaypalExpressCheckoutTest : ACQE-8007
StoreFrontSimpleProductWithSpecialAndTierDiscountPriceTest : ACQE-7971

The consistent test failure for Functional CE is known Issues and JIRA is raised for the same. Other failures are inconsistent and seems to be flaky. They neither part of PR nor failing because of the PR changes.

Build 1: https://public-results-storage-prod.magento-testing-service.engineering/reports/magento/magento2/pull/39690/e517e2b946161599488a7d675914bbf4/Functional/allure-report-ce/index.html#categories/8fb3a91ba5aaf9de24cc8a92edc82b5d

image

Build 2: https://public-results-storage-prod.magento-testing-service.engineering/reports/magento/magento2/pull/39690/b6ec0d558b51716982ef4f365b19bb1c/Functional/allure-report-ce/index.html#categories/8fb3a91ba5aaf9de24cc8a92edc82b5d

image

Known Issues:
EnablePaypalExpressCheckoutAndSubmitAnOrderUsingPaypalExpressCheckoutTest : ACQE-8007

The consistent test failure for Functional EE is known Issues and JIRA is raised for the same. Other failure is inconsistent and seems to be flaky. They neither part of PR nor failing because of the PR changes.

Build 1: https://public-results-storage-prod.magento-testing-service.engineering/reports/magento/magento2/pull/39690/3049098b7d976dbc2eb8751f3e56e025/Functional/allure-report-ee/index.html#categories/8fb3a91ba5aaf9de24cc8a92edc82b5d

image

Build 2: https://public-results-storage-prod.magento-testing-service.engineering/reports/magento/magento2/pull/39690/7de1f6d980021ed16813b17760fb9d7d/Functional/allure-report-ee/index.html#categories/8fb3a91ba5aaf9de24cc8a92edc82b5d

image

Known Issues:
EnablePaypalExpressCheckoutAndSubmitAnOrderUsingPaypalExpressCheckoutTest : ACQE-8007

hence moving this PR in Merge In Progress

@engcom-Dash engcom-Dash moved this from Extended testing (optional) to Merge in Progress in Community Dashboard Jun 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Partner: Perspective partners-contribution Pull Request is created by Magento Partner Priority: P3 May be fixed according to the position in the backlog. Progress: ready for testing Project: Community Picked PRs upvoted by the community
Projects
Status: Merge in Progress
Development

Successfully merging this pull request may close these issues.

Special Price To Date is wrongly validated on applySpecialPrice
8 participants