akukameda

Hello,

Following up on my previous query regarding the incorrect WP-Cron scheduling time (the event consistently running at 9:00 AM JST).

I have investigated the code in version 2.7 and successfully implemented a fix locally. The issue is confirmed to be related to the timezone handling when the expiry timestamp is calculated.

The Cron hook woo_expiry_schedule_action is being scheduled using PHP’s standard strtotime() which does not account for the WordPress timezone setting, leading to the 9-hour JST offset.Technical Details & Proposed Solution

The incorrect scheduling logic is present in both the save_variation_fields() and save_fields() methods.

To properly schedule the expiry action for midnight (00:00:00) in the site’s local timezone, the timestamp calculation needs to be updated.

Here is the robust solution I implemented using PHP’s DateTime class, which correctly respects the WordPress timezone string:

1. Add a Private Helper Method to the Main Plugin Class:

Please add this method inside the main plugin class (e.g., WOO_Product_Expiry):

PHP

private function get_wp_timestamp_for_midnight( $date_string ) {
    $tz_string = get_option( 'timezone_string' ) ? get_option( 'timezone_string' ) : 'UTC';
    $timezone = new DateTimeZone( $tz_string );

    $datetime = new DateTime( $date_string, $timezone );
    $datetime->modify('+1 day');
    
    return $datetime->getTimestamp();
}

2. Update the Scheduling Logic in both save_fields() and save_variation_fields():

Replace the old $scheduleOn = strtotime(...) calculation with a call to the new method.

Example Update for save_fields():

PHP

// Old: $scheduleOn = strtotime("+1 day", strtotime($woo_expiry_date));

$expiry_date_str = date('Y-m-d', strtotime($woo_expiry_date));
$scheduleOn = $this->get_wp_timestamp_for_midnight( $expiry_date_str );

// Continue with wp_clear_scheduled_hook and wp_schedule_single_event...

I can confirm that after applying this fix and resaving a product, the woo_expiry_schedule_action is now correctly scheduled for 00:00:00 in JST.

I hope this helps your team patch this bug in the next update.

Thank you for your attention.

Best regards,