Bug Description

@aaemnnosttv noticed that the timestamp for him appears to be GMT or similar for all workers:

Also the quarterly worker is one hour later than the others.

These should be scheduled based on the default timezone of the account.

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• Every scheduler should be scheduled for midnight on the day of the end of the relevant period, in the default timezone of the site.

Implementation Brief

The drift seems to happen because the batch timestamp is currently set with time() at execution, so if WP‑Cron fires late, workers, fallbacks, and reference dates are anchored to the execution time, not the scheduled midnight in the site timezone.

• Schedule initiator with the computed timestamp Email_Reporting_Scheduler.php
  • In schedule_initiator_once() and schedule_next_initiator(), schedule the initiator with args [ $frequency, $next_timestamp ] (instead of only $frequency).
• Accept the timestamp in the initiator callback Email_Reporting.php:
  • Update the initiator hook to accept 2 args (add_action( Email_Reporting_Scheduler::ACTION_INITIATOR, ...., 10, 2)
• In Initiator_Task.php:
  • handle_callback_action method should use $scheduled_timestamp instead of current time()
  • Use this timestamp for:
    • schedule_worker( …, $scheduled_timestamp )
    • schedule_fallback( …, $scheduled_timestamp )
    • build_reference_dates( …, $scheduled_timestamp )

Test Coverage

• Email_Reporting_SchedulerTest.php
  • Update assertions to include the new args [ $frequency, $expected_timestamp ].
• Initiator_TaskTest.php
  • Add a test to assert that when handle_callback_action is called, the worker and fallback schedules receive the same $scheduled_timestamp
• Frequency_PlannerTest.php
  • Use a fixed UTC timestamp and compute next_occurrence for UTC vs America/Los_Angeles for example.
  • Assert the timestamps are not equal and each resolves to midnight in the respective timezone.

QA Brief

It was historically a bit difficult to reproduce this issue. You can try to QA this issue using these steps:

• Set site timezone in Settings > General to a non-UTC zone (e.g. America/Los_Angeles).
• Enable email reporting and subscribe to a frequency, eq weekly.
• In Tools > Cron Events (WP Crontrol plugin is needed), check googlesitekit_email_reporting_initiator events:
  • args include [frequency, scheduled_timestamp]
  • scheduled time is local midnight for that period boundary.
• Trigger initiator event for selected frequency (weekly if you subscribed to weekly reports) manually (Run Now) and verify new worker/fallback events are created with the same initiator timestamp in args.
• Verify email report align with the scheduled day, not the actual run time.
• Switch timezone to UTC, reschedule, and confirm timestamps shift accordingly while still landing on midnight in that timezone. After switching the timezone setting, note that scheduled CRON is still running on initial setting during which it was scheduled. So to force it to reschedule under new timezone, delete the scheduled CRON so it can be recreated under new timezone

Changelog entry

• Fix timezone bugs with scheduled emails.