You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the first day of a month is not a Monday, we simply take the first day of the first week.
Therefore, the 'week' attribute can not define a week starting on Monday. It has to define a partial week.
The following code should schedule the task for the very last day of the month:
$monthly->setDay(7);
$monthly->setWeek(4);
If the last day of a month is not a Sunday, we simply take the closest day to the one specified.
How about if the month has 6 partial weeks? In this case, even though the API user meant to schedule the task for the last day of the month, it wouldn't work.
The only solution I could think of is a comment in the code saying: "To be absolutely certain the task is scheduled for the last day, use ->setWeek(6)".
If a month has less than 6 weeks, we would simple take the last week.
The following code should schedule the task for the Tuesday of the first week of the month:
$monthly->setDay(2);
$monthly->setWeek(1);
What happens if there is no Tuesday the first week of a given month? Do we set for Tuesday of the next week? do we take the first day of the first week?
Those 3 points clearly indicate that keeping this API is a mess from a usability point of view.
Solution 2: Define a reduced API for monthly scheduled tasks [RECOMMENDED]
The API for monthly scheduled tasks should be remade.
Here are two proposals:
Remove setWeek() and use setDay()
In this solution, setWeek() would be removed and setDay() would be used with integers comprised within 1 and 31.
To schedule a task for the very last day of a month, we would use setDay(31) and pick the closest day for months with less than 31 days.
Remove setDay() and setWeek(), add runFirstDay(void) and runLastDay(void)
To schedule the task for the first day, runFirstDay() would be called, to schedule the task for the last day, runLastDay() would be called.
Please comment on the best way to go.
The text was updated successfully, but these errors were encountered:
This bug has been brought on the forum: Topic 15651
In /core/ScheduledTime.php and core/ScheduledTime/Monthly.php I failed to precisely define what is a "week":
From here, there are two ways to go.
Solution 1: Keep the API & Fix edge cases RECOMMENDED
The first solution is to keep the API as it is and add the following fixes:
According to the 'day' attribute, setDay(1) means Monday.
If the first day of a month is not a Monday, we simply take the first day of the first week.
Therefore, the 'week' attribute can not define a week starting on Monday. It has to define a partial week.
If the last day of a month is not a Sunday, we simply take the closest day to the one specified.
How about if the month has 6 partial weeks? In this case, even though the API user meant to schedule the task for the last day of the month, it wouldn't work.
The only solution I could think of is a comment in the code saying: "To be absolutely certain the task is scheduled for the last day, use ->setWeek(6)".
If a month has less than 6 weeks, we would simple take the last week.
What happens if there is no Tuesday the first week of a given month? Do we set for Tuesday of the next week? do we take the first day of the first week?
Those 3 points clearly indicate that keeping this API is a mess from a usability point of view.
Solution 2: Define a reduced API for monthly scheduled tasks [RECOMMENDED]
The API for monthly scheduled tasks should be remade.
Here are two proposals:
In this solution, setWeek() would be removed and setDay() would be used with integers comprised within 1 and 31.
To schedule a task for the very last day of a month, we would use setDay(31) and pick the closest day for months with less than 31 days.
To schedule the task for the first day, runFirstDay() would be called, to schedule the task for the last day, runLastDay() would be called.
Please comment on the best way to go.
The text was updated successfully, but these errors were encountered: