Description
Symfony version(s) affected
6.4
Description
Description
When using RecurringMessage::every() with multiple weekdays and a specific timezone in the DateTimeImmutable object, the schedule fails to trigger on the last day in the comma-separated list. The last day in the list is always ignored.
How to reproduce
<?php
declare(strict_types=1);
namespace App\Messenger\RecipeReport;
use DateTimeImmutable;
use DateTimeZone;
use Symfony\Component\Scheduler\Attribute\AsSchedule;
use Symfony\Component\Scheduler\RecurringMessage;
use Symfony\Component\Scheduler\Schedule;
use Symfony\Component\Scheduler\ScheduleProviderInterface;
#[AsSchedule('RecipeReport')]
class RecipeReportProvider implements ScheduleProviderInterface
{
public function __construct(private readonly array $recipients)
{
}
public function getSchedule(): Schedule
{
return new Schedule()->add(
RecurringMessage::every(
'Monday, Thursday, Saturday',
new RecipeReportMessage($this->recipients),
new DateTimeImmutable('12:05:00', new DateTimeZone('Europe/Warsaw'))
)
);
}
}Expected behavior: The message should be dispatched every Monday, Thursday, and Saturday at 12:05:00 Europe/Warsaw time.
Actual behavior: The message is dispatched only on Monday and Thursday. Saturday (the last day in the list) is ignored.
Additional test case:
When changing the list to 'Monday, Thursday, Saturday, Sunday':
- Expected: Message dispatched on Monday, Thursday, Saturday, and Sunday
- Actual: Message dispatched on Monday, Thursday, and Saturday. Sunday (now the last day) is ignored.
Pattern observed
The last day in any comma-separated list of weekdays is consistently ignored when a timezone is specified:
'Monday, Thursday, Saturday'→ works for Monday and Thursday only'Monday, Thursday, Saturday, Sunday'→ works for Monday, Thursday, and Saturday only'Tuesday, Friday'→ works for Tuesday only
Possible Solution
The issue appears to be in the parsing logic of the weekday list when combined with timezone handling. There might be an off-by-one error or incorrect string parsing that causes the last element to be dropped.
Additional Context
- The issue only occurs when specifying a timezone in the DateTimeImmutable constructor
- The workaround is to add a dummy day at the end that you don't actually need
- This behavior is consistent regardless of which days are used or their order
Possible Solution
No response
Additional Context
No response