PayPal Express: profile_start_date Treated as UTC Instead of Site Timezone, Causing Subscription Start Time Shift

[MaryOJob]

A customer using PayPal Express with their site set to UTC+9 noticed that subscriptions are starting approximately 9 hours earlier than expected. They suspect the issue lies in the pmpro_calculate_profile_start_date() function, where the site's local time may be treated as UTC when passed to PayPal, causing a timezone mismatch.

I recreated this issue on a test site using PayPal Express and can confirm that the subscription start time sent to PayPal appears to be offset by the site's timezone (+9 hours in this case), causing the first billing cycle to be shortened.

This misalignment only appears with PayPal Express and does not occur when using Stripe.

To Reproduce
Steps to reproduce the behavior:

1. Set the site timezone to UTC+9 in WordPress (Settings > General).
2. Ensure PHP is also configured to use UTC+9 (via php.ini or similar).
3. Use PayPal Express Checkout as the payment gateway.
4. Create a daily recurring subscription level in PMPro.
5. Perform a checkout as a test user at your site’s local time (e.g., 17:53:31 on July 4, 2025).
6. After checkout: View the subscription in PayPal dashboard.
7. Note that the start date is shown as July 5, 2025 (midnight UTC).
8. Inside PMPro, observe that the next payment date shows July 5, 2025 at 6:00 PM, confirming a ~9-hour offset between what PMPro expects and what PayPal processed.

Expected behavior
When a user checks out using PayPal Express, the profile_start_date sent to PayPal should be properly converted to UTC. As a result, the subscription should begin exactly at the correct local time on the site, with no time offset or shortened billing period.

Isolating the problem (mark completed items with an [x]):

• I have deactivated other plugins and confirmed this bug occurs when only Paid Memberships Pro plugin is active.
• This bug happens with a default WordPress theme active, or Memberlite.
• I can reproduce this bug consistently using the steps above.

WordPress Environment

Details

``` WordPress 6.8.1 Memberlite 6.0.1 PMPro Version 3.4.7 PHP 8.0.30 PMPro PayPal Express 0.7.1 ```

[wataru5963]

I have summarized my test results in the following gist:
https://gist.github.com/wataru5963/7871ec58a20d9cd08b2b1a7b0cba7e07

Regarding the potential cause of the problem, I believe the timestamp passed as an argument to date_i18n should be passed as timestamp_with_offset and needs to be "A sum of Unix timestamp and timezone offset in seconds."
It might be better to use wp_date instead.
https://developer.wordpress.org/reference/functions/date_i18n/

Alternatively, we could use DateTime with explicit UTC timezone to avoid timezone interpretation issues:

$utc = new DateTime('now', new DateTimeZone('UTC'));
$utc->modify(sprintf('+%d %s', $level->cycle_number, $level->cycle_period));
$correct_utc_date = $utc->format('Y-m-d\TH:i:s\Z');

This approach would ensure the date is explicitly handled in UTC before being sent to PayPal.