The current release versions of Tasks Pro™ and Tasks suffer from a nasty PHP oddity in their daily recurring task functionality.
When you create a recurring task in Tasks Pro™/Tasks, all future occurrences are created in the database, and they are activated over time.
I used a very basic system to set the dates on the recurring tasks. Programatically, it's easy to represent a date in seconds, then you can add seconds to that number to move forward/back in days (1 day = 86400 seconds (60 seconds in a minute * 60 minutes in an hour * 24 hours in a day). For recurring tasks that were defined to recur every N days, I would take the date of the previous task, add 86400 to that date, and so on and so forth.
As it turns out, this worked for every day of the year except October 31 this year (and, I assume, the day of the DST switch in the fall going forward as well). It seems that on the day of the DST switch, adding 24 hours to the day doesn't move forward by 1 day as you might expect. Instead, to move past this day you need to add 25 hours!
Here is a simple script to illustrate this:
print('<ol>');
$date = mktime(0, 0, 0, 10, 20, 2004);
for ($i = 0; $i < 30; $i++) {
print(
'<li>'
.date("Y-m-d", $date)
.'</li>'."\n"
);
$date += 86400;
}
print('</ol>');
If you run that code, you'll see that October 31 shows up twice.
Now if you were using a date variable, adding 24 hours to it, and resetting the new date to only the YYYY-MM-DD of the new date, you would never actually move past 10-30. And that is what happened in Tasks Pro™/Tasks. Instead of continuing to create tasks on into November, it just kept looping and creating tasks on 10-30. The easiest solution (assuming you are resetting your date variable to the YYYY-MM-DD value each time) is to simply add 25 hours to the previous date instead of 24.
I'm not sure how many customers were affected by this as I only heard from 2 that had experienced this issue. My apologies for the inconvenience this must have caused.
I've fixed the problem and a patch has been applied to Use Tasks accounts already. The next beta releases of Tasks Pro™ 1.6 and Tasks 2.6 will also include the patch.
Popularity: 4% [?]
Link adds this Comment:
I had the EXACT same problem at work on Friday and it took me awhile to figure out what was happening.
I switched from adding 86400 to using a mktime with date(”d”) + 1. I’m not sure that was the best way to get around this, but it seems to be holding up.
November 2nd, 2005 at 4:40 pm
Alex adds this Comment:
I’m using 90000.
November 2nd, 2005 at 4:59 pm
Dan Coulter adds this Comment:
This happened to be the first year that I ran into this exact same problem. I found that you could do this, though:
$tomorrows_timestamp = strtotime(”+1 day”, $todays_timestamp);
That’ll give you an integer value for one day in the future. It even corrects for Daylight Savings.
November 3rd, 2005 at 1:37 pm
Elliot Anderson adds this Comment:
I have always used strtotime() and I have never had a problem with it.
November 3rd, 2005 at 10:24 pm