I applied this patch and tried to change settings of a task:

When saving this settings:

PHP 8.0, win11 and xampp

The removed helper PHP will have to be added to the list of files to be deleted on update in script.php. I will do that when this PR has been merged.

@ditsuke I think @chmst indeed found an issue with your changed code, possibly here: https://github.com/joomla/joomla-cms/pull/36439/files#diff-b9f75ae33fad36d7a8968d12a2b78ec972c5e6d2c6fd7ed0024d764191ec48ecR572 .

Possibly a type cast to object is not sufficient. I don't have looked up now what the constructor expects.

@chmst @richard67 thanks for identifying the issue and the source! The latest commit should solve it. Please test.

You fixed the code error, but I don't understand why the Task Params are twice. First in tab "New Task" and in tab "Advanced"?

You fixed the code error, but I don't understand why the Task Params are twice. First in tab "New Task" and in tab "Advanced"?

@chmst I addressed that in #36515 (needs test). We need the routine parameter fieldset to have a showFront="true" attribute at the moment. Although I don't think that's ideal, this PR should work for now. Let's try to work on removing this requirement in the future!

Could we please get a couple tests on this ?

This pull request has automatically rebased to 4.2-dev.

@ditsuke this PR is still open. could you please resolve the conflicts so that we can re-test?

This pull request has been automatically rebased to 5.0-dev.

This pull request has been automatically rebased to 5.1-dev.

This pull request has been automatically rebased to 5.2-dev.

I have tested this item ? unsuccessfully on 4f91c6a

I opened an existing task, changed a setting, saved and closed and got a 500 error:

An error has occurred.
0 Class "Joomla\Component\Scheduler\Administrator\Model\ExecRuleHelper" not found
Call Stack

Function Location

1 () JROOT/administrator/components/com_scheduler/src/Model/TaskModel.php:571
2 Joomla\Component\Scheduler\Administrator\Model\TaskModel->save() JROOT/libraries/src/MVC/Controller/FormController.php:689
3 Joomla\CMS\MVC\Controller\FormController->save() JROOT/libraries/src/MVC/Controller/BaseController.php:730
4 Joomla\CMS\MVC\Controller\BaseController->execute() JROOT/libraries/src/Dispatcher/ComponentDispatcher.php:143
5 Joomla\CMS\Dispatcher\ComponentDispatcher->dispatch() JROOT/libraries/src/Component/ComponentHelper.php:361
6 Joomla\CMS\Component\ComponentHelper::renderComponent() JROOT/libraries/src/Application/AdministratorApplication.php:150
7 Joomla\CMS\Application\AdministratorApplication->dispatch() JROOT/libraries/src/Application/AdministratorApplication.php:195
8 Joomla\CMS\Application\AdministratorApplication->doExecute() JROOT/libraries/src/Application/CMSApplication.php:306
9 Joomla\CMS\Application\CMSApplication->execute() JROOT/administrator/includes/app.php:58
10 require_once() JROOT/administrator/index.php:32

@cybersalt same as this comment

This pull request has been automatically rebased to 5.3-dev.

This pull request has been automatically rebased to 6.0-dev.

This pull request has been automatically rebased to 6.1-dev.

This pull request has been automatically rebased to 6.2-dev.

Testing this PR against the current 5.4 behavior surfaced a timezone regression in the cron-expression branch of Task::computeNextExecution().

The current ExecRuleHelper passes the site's configured timezone: getNextRunDate('now', 0, false, Factory::getApplication()->get('offset', 'UTC')), then normalizes to UTC. This PR replaces that with a hardcoded getNextRunDate('now', 0, false, 'UTC').

On any site whose Server Time Zone is not UTC, that changes when tasks fire, and for infrequent expressions it silently skips whole periods. Concrete reproduction (dragonmantank/cron-expression 3.4.0 and 3.6.0, identical results; PHP default tz UTC, site offset America/Chicago, monthly 0 5 1 * *):

now = 2026-07-01 06:00 UTC (01:00 America/Chicago)
current code -> 2026-07-01 10:00 UTC  (= 05:00 local, correct)
this PR      -> 2026-08-01 05:00 UTC  (July run silently skipped)

Same class of skip on yearly expressions at the year boundary. The current behavior is also the one consistent with the rest of com_scheduler: the tasks list renders next_execution through HTMLHelper::_('date', ...) in the user's timezone, so an admin who entered a 05:00 schedule sees 05:00 only if the stored UTC instant corresponds to local time, which is what the offset-aware calculation produces. It also tracks DST correctly, where the hardcoded-UTC version drifts.

Suggested fix: keep the fourth argument as Factory::getApplication()->get('offset', 'UTC') (plus the existing setTimezone(new \DateTimeZone('UTC')) normalization) in computeNextExecution(). Happy to share the full standalone test harness if useful.