Password creation/reset link not working on certain timezones

[AlexandreKhayrullin]

Preconditions

1. Set the timezone to America/Santiago.

Steps to reproduce

1. Create a new customer or update an existing one in the backend. An e-mail will be sent.
2. In the received e-mail, click on the link for creating or resetting a password.

Expected result

1. The user is redirected to the form where they can enter their new password.

Actual result

1. A session message pops-up, saying that the link has expired.

Here is a more detailed description of the issue and the proposed solution:

After receiving an e-mail sent after a password change request and clicking on the button "Set a New Password", depending on the timezone set on the store, the link can be always marked as "expired". This is the case, for instance, for stores set in Chili (timezone: "America/Santiago") .

The problem resides in the method \Magento\Customer\Model\AccountManagement::isResetPasswordLinkTokenExpired() , where the method reads the token timestamp, that has been stored in UTC on creation, and considers it to be in the store's timezone.

To solve the issue, replace this line in the method:

$tokenTimestamp = (new \DateTime($rpTokenCreatedAt))->getTimestamp();

with this one:

$tokenTimestamp = (new \DateTime($rpTokenCreatedAt,new \DateTimeZone('UTC')))->getTimestamp();

[veloraven]

@AlexandreKhayrullin thank you for your report.
Please, identify which version of Magento you are running.

[AlexandreKhayrullin]

I'm running the development branch, updated frequently.

[sevos1984]

I can't reproduce this, what is you server timezone and customer's timezone?

[AlexandreKhayrullin]

The server's timezone is "CEST" (UTC+0200). The frontend's timezone is "America/Santiago" (UTC-0400) , defined on the website scope. The backend, on the other hand, uses the default timezone (no special configuration in the core_config_data table) .

[Ctucker9233]

I think this bug is also affecting the newsletter queue. See issue #5943. In the comments I attempted to trace where the problem might be coming from.

[sevos1984]

So your website timezone is different from default config, try setting default timezone same to your server timezone

[AlexandreKhayrullin]

The Magento platform we are putting in place is supposed to cover multiple countries and multiple timezones, so if we do this, the links will only work for one timezone.

[Ctucker9233]

@sevos1984 I tried that. I set the timezone to Central/Chicago, same as my server. When I go to queue up a newsletter, the send time shows up as two hours ahead of my time (Pacific) like it should. But as soon as I hit send/save and it redirects to the newsletter queue grid, the send time is shifted back five hours. So for example, my local time is 5:20pm. In the newsletter queue set up part, it will show my current time as 7:20. I set the queue start time to 6:20 because I am just testing and I don't want anything to actually send. I give it the command to send and in the newsletter queue grid, the queue start time shows as 1:20 PM. If you read my trace in the issue I referenced, I mention a file in which some sort of time offset is supposed to be created. I imagine that is supposed to calculate the difference between UTC and the user's local time so that everything in magento's backend will display with the user's local time. However, that offset doesn't seem to be occuring in the newsletter queue. It seems to revert to straight UTC time, which will always result in an unsent newsletter. I don't always have the luxury of planning 5 or 6 hours ahead.

[sevos1984]

There are several issues with newsletter queue #2937 and #5943. Looks like the same with your issue.

[AlexandreKhayrullin]

It appears that, in many features, dates are not being saved and/or read as UTC (as was the case in Magento 1) , using the timezone from the context instead.

I really hope this is not a design choice.

[sevos1984]

No, this is particular bug for newsletter. Please refer to #2937 or #5943 to know when issue will be fixed. Thanks for reporting.