I encountered an interesting problem with Scheduled Reminders:
- The client was saying that the Scheduled Reminders seemed to be running with UTC time, instead of UTC+3 in their case. We could confirm it was the case, looking at the civicrm logs and the activity table.
- I debugged it to where
CRM_Core_BAO_ActionSchedule::processQueue gets the $now using CRM_Utils_Time::getTime(), and that boils down to running time().
cv cron -vvv mentions setting the timezone, and looking at the code, I see that it calls \CRM_Core_Config::singleton()->userSystem->setTimeZone(). On Drupal10, this seems to be CRM_Utils_System_Base::setTimeZone(), which I was able to confirm with tracing. This uses date_default_timezone_get().
The PHP docs state that date_default_timezone_get() will return UTC, if not set in the PHP config explicitly.
I can workaround the issue by adding a date_default_timezone_set() statement in the civicrm.settings.php, but that's not a very convenient fix.
I will dig into the timezone settings for Standalone, and if it might make sense to expose it for all CMSes?
I encountered an interesting problem with Scheduled Reminders:
CRM_Core_BAO_ActionSchedule::processQueuegets the$nowusingCRM_Utils_Time::getTime(), and that boils down to runningtime().cv cron -vvvmentions setting the timezone, and looking at the code, I see that it calls\CRM_Core_Config::singleton()->userSystem->setTimeZone(). On Drupal10, this seems to beCRM_Utils_System_Base::setTimeZone(), which I was able to confirm with tracing. This usesdate_default_timezone_get().The PHP docs state that
date_default_timezone_get()will return UTC, if not set in the PHP config explicitly.I can workaround the issue by adding a
date_default_timezone_set()statement in thecivicrm.settings.php, but that's not a very convenient fix.I will dig into the timezone settings for Standalone, and if it might make sense to expose it for all CMSes?