+ Add Question

Why, after an task is marked done after midnight, isn't "every day" generating tasks properly?

I have a task that must be repeated "every day" and the due date is set to "every day". Sometimes the task is done after midnight on the day it's due, making it overdue, because that's the nature of the task. However, when I mark it "done" and a new task is generated, the new task lands in tomorrow's list of tasks, not today's. This is incorrect. It should be placed in today's task because the recurring nature of the task *should be* based on when it was due (since we're after mid-night, yesterday), not when it was done. Therefore the newly generated task should show up in *today's* list of task.

If I had used "after 1 day" then, yeah, the date should be calculated based on the done date, today, and placed in tomorrow's list.

I just recently move over from RTM after using it for many years because of a number of things I prefer about TD (primarily the UI). However, this bad date calculation (which RTM does correctly) could become an issue. I assume the invalid date calc is done on all "every x days" that are marked complete when overdue.

Your documentation and I agree: "after 1 day" and "every 1 day" are not the same. Please fix ASAP.

Thank you.

P.S. As an aside, I think combining the due date and the recurring formula in the same field is dangerous and isn't the best design choice. If I want to move the current due date of an item that has a, for example, "after x days" recurring pattern, I shouldn't have to juggle those two data elements in one field. Again, not that RTM is the superior product in most other areas, but they get it right on this point as well.

All responses

Brendon Wadey  staff
Replied on Feb 24, 2014 - 00:06 UTC

Hi Joey,

This is a debate that we have fairly often, and we do not see a better solution at this time. If you have 5 days overdue, and we followed your way of processing a task, then you'd need to complete 5 more tasks before getting to the current one. Instead, when you check this off it moves to the next occurrence.

The downside, is of course that it can sometimes skip the current day. The solution at this time is using the "Today" button if it's overdue, instead of completing it. Not ideal though. It happens due to how our system calculates the overdue days, and how it knows how to move to the next occurrence.

Then again, many things have changed with our syntax and system recently, so I will look into it with the developers, as it may be possible to change this to a better solution now.


Joey  premium
Replied on Feb 24, 2014 - 00:32 UTC

Thanks for the reply Brendon. I understand the concern of having the possibility of continually creating overdue tasks.

However, I don't understand what the debate is: If the user created a task repeat pattern that's "every day" and they're not postponing that task, then the software shouldn't second-guess the user by skipping those days. In other words, if the logic of the repeat pattern is 5 more tasks before getting to the current one, then so be it. The solution would then be in the hands of the user to change their repeat plan or get current and would take the responsibility away from the folks at Todoist to think on the behalf of, and take the initiative away from, the user.

If that's not how you guys want to think about it, then I'd strongly suggest that you consider this: make the next occurrence the *earliest non-overdue day* that would comply with the repeat pattern when completing an overdue task -- which in the case of an "every day" task, would be today, not tomorrow.

This is a vital feature. So many people gravitate to task managers to free their minds from worrying about details such as this. It's hardly productive, indeed it's counter-productive, the antithesis of why your software exists, for a user to have to always be mindful of a "nuance" such as this on the part of the tool provider. Please make repeating tasks work exactly right, both types, "after" and "every."

You have a great product with few bugs. Besides this one, the bugs I've found are transient and related to the UI and UX. However, this bug is is a fundamental logical flaw that really needs correcting soon.


Brendon Wadey  staff
Replied on Feb 24, 2014 - 01:03 UTC


Thanks for that. I will indeed pass this to the team and look into the reasoning for what is going on. It's possible things will change, as much of the code as changed recently.


Replied on Mar 14, 2014 - 10:58 UTC

I have to agree, this is a major pain. Not all tasks can be completed before they are due. And to have to check and reset the repeating function if it is late enough defeats the purpose of the repeating function.

Joey  premium
Replied on Mar 24, 2014 - 01:28 UTC

Hi Brendon, any progress on this issue?

Brendon Wadey  staff
Replied on Mar 24, 2014 - 02:05 UTC


No news on this as of yet. The truth is we do have some other concerns at the moment, so it may be a bit delayed before we look into this "philosophy change" idea.