-
-
Notifications
You must be signed in to change notification settings - Fork 825
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
Convert Paypal Standard IPN payment_date to system's time zone #13439
Convert Paypal Standard IPN payment_date to system's time zone #13439
Conversation
Can one of the admins verify this patch? |
(Standard links)
|
Jenkins ok to test |
@@ -394,6 +394,8 @@ public function getInput(&$input, &$ids) { | |||
$paymentDate = $this->retrieve('payment_date', 'String', FALSE); | |||
if (!empty($paymentDate)) { | |||
$receiveDateTime = new DateTime($paymentDate); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
won't you have to specify that its in Pacific time on creation or is it doing that sensibly already? Also do we need to do this for PayPalPro IPNs as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is from one of the test IPN messages: payment_date=22:08:43 Jan 11, 2019 PST
But yeah, if the time zone wasn't supplied, this wouldn't work.
Pro does look to require it as well, but the code structure for that was... a bit different:
https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment/PayPalProIPN.php#L318
// CRM-13737 - am not aware of any reason why payment_date would not be set - this if is a belt & braces
$objects['contribution']->receive_date = !empty($input['payment_date']) ? date('YmdHis', strtotime($input['payment_date'])) : $now;
and https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment/PayPalProIPN.php#L534:
$input['payment_date'] = $input['receive_date'] = self::retrieve('payment_date', 'String', 'POST', FALSE);
Since I admittedly don't have a setup for "properly" testing things, and don't have access (and have never used) PayPal pro, I didn't feel comfortable taking a completely dark stab - especially with payment_date
being referenced in two locations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -394,6 +394,8 @@ public function getInput(&$input, &$ids) { | |||
$paymentDate = $this->retrieve('payment_date', 'String', FALSE); | |||
if (!empty($paymentDate)) { | |||
$receiveDateTime = new DateTime($paymentDate); | |||
$systemTimeZone = new DateTimeZone(CRM_Core_Config::singleton()->userSystem->getTimeZoneString()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jgillmanjr Can you add a couple of lines of comments into the code here explaining why we need to do the timezone conversion (so anyone looking at this code in the future can work out what is going on and why). Eg. add a sample payment_date as it comes in from paypal etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comments in 292785c
Aaanddd apparently pulling in the latest from master killed the build... |
@jgillmanjr You need to do a git "rebase". Something like |
Co-Authored-By: jgillmanjr <jason@rrfaae.com>
292785c
to
6800eef
Compare
Welp, hopefully that didn't bork things up too bad |
I'm happy with this PR from a technical point of view. @pradpnayak Would you be able to test this? |
@mattwire this is incase of subsequent payment callback for recurring? |
@pradpnayak no this is just so that the transaction date that is recorded in CiviCRM is when it actually happened in the System's local time not in PayPal's time |
Australian Greens have released this to our production environment and the dates are looking correct for us now @mattwire @pradpnayak @eileenmcnaughton are you folks satisfied this is fine to merge? |
Jenkins re test this please |
@seamuslee001 yes - you have tested it & @mattwire said "I'm happy with this PR from a technical point of view" |
Merging based on Matt and I's review |
@seamuslee001 @jgillmanjr this caused a regression :-( when accessing the ipn through the old path - see https://lab.civicrm.org/dev/drupal/issues/66 |
Overview
Convert
payment_date
received with the Paypal Standard IPN to the system's time zoneBefore
Currently,
payment_date
is set to (presumably) the local time for Paypal (a Pacific time zone ofPST
orPDT
is part of the timestamp). This leads to the wrong time being written to the database.After
The timestamp is adjusted to the system's time zone.
Technical Details
Relatively straight forward fix.
Just build a
DateTimeZone
object for the system's TZ and convert the$receiveDateTime
objecting using thesetTimezone
method.