clare, i think “when done” means exactly that, whether the task is done early, on the date or past the due date. the next event and next due are both calculated from the done date. to me the “when done” means that the task hapens “every N days days from when I complete the task, whether I get done early, on time or late”.

@claremacrae will do ill have it up by tomorrow

Wow, thank you for 3 extremely helpful messages, @schemar @pcause @rhhub.

OK, so clearly when done will not change in its behaviour. I may add some of schemar’s examples to the docs.

@schemar said:

@claremacrae I think it’s a good idea to add a new qualifier in addition to when done if there is sufficient demand. Adding more options in addition to when done adds more code that must be maintained to the “recurrence” code, which appears to be one of the trickiest parts of Tasks as it stands.

Though maybe the code—change is small and worth it 👍🏻

I refactored the code recurrence code before picking up this issue, so its calculation of next reference date is quite easy to reason about now.

https://github.com/obsidian-tasks-group/obsidian-tasks/blob/06f8f384049eba0d5c883a3ecc231abb05c2a8d8/src/Recurrence.ts#L191C1-L199

@pcause said:

clare, i think “when done” means exactly that, whether the task is done early, on the date or past the due date. the next event and next due are both calculated from the done date. to me the “when done” means that the task hapens “every N days days from when I complete the task, whether I get done early, on time or late”.

Yep. I won’t change it.

@rhhub

In regards to the naming of the implementation currently described as when overdue. I think when overdue doesn’t describe what happens when something is completed early.

OK I will think about your suggestions…

---

So, what to do about this issue?

I think that virtually all the discussion is worded around changing the behaviour of when done - and then the conclusion was not to.

So I am inclined to:

• close this one as won't do
• then create a new one that requests a new recurrence option that selects the new date based on:

1. If early calculate next due date wrt current due date.
2. If overdue calculate next due date wrt completion date.
3. Due date = completion date.

@claremacrae

In regards to the naming of the implementation currently described as when overdue. I think when overdue doesn’t describe what happens when something is completed early.

Cases that need to be represented

1. If early calculate next due date wrt current due date.
2. If overdue calculate next due date wrt completion date.
3. Due date = completion date.

The following are names I think could describe these cases.

1. keep next
2. stay next
3. from next
4. when next
5. keep new
6. stay new
7. from new
8. when new
9. keep current
10. stay current
11. from current
12. when current

I like from the most. I like from so much that, I think from done would make a good alias for when done.

Bottom line up front: I wouldn’t change the current behavior, as current users expect the current behavior.

@claremacrae let me know if you need more input from me.

---

In my opinion, the current behavior is expected. However, please note that I also think that there is no objectively correct answer to how it should work.

I think we all expect the current behavior for every … without when done. So I won’t comment on that.

Regarding when done, below are some examples that illustrate use-cases for the current behavior. I understand that there are also use-cases for different behavior, but that doesn’t invalidate the ones below, which are currently supported by Tasks. And a decision had to be made at some point to support one or the other.

Also, I consider every week on Sunday when done a special case. With the current behavior, it only makes sense if the previous due date is more than one week overdue. So you probably want every week on Sunday without when done (same for monthly on a specific day).

---

@claremacrae I think it’s a good idea to add a new qualifier in addition to when done if there is sufficient demand. Adding more options in addition to when done adds more code that must be maintained to the “recurrence” code, which appears to be one of the trickiest parts of Tasks as it stands.

Though maybe the code—change is small and worth it 👍🏻

---

Examples That Use The Current Behavior

Recurring Contact

Alice wants to talk to Bob regularly. She thinks four weeks is a sensible interval and schedules a task to contact Bob every 4 weeks when done.

Two weeks after she contacted Bob, he calls her. Now they had contact and Alice marks the task done.

The next occurrence should be in 4 weeks, not in 6.

Taking Out The Trash

Alice knows that she needs to take out the trash roughly every 5 days, so she schedules a task to take out the trash every 5 days when done. It’s always empty when she took it out so she wants to base recurrence on “when done”.

She won’t be home much the next two days, so she manually schedules the task to be done in 7 days (still every 5 days when done).

Two days later, friends surprise her at her place and they have a party. At the end of the day, the trash is full and Alice takes it out. She marks the task as done.

The next occurrence of the task should be in 5 days, not in 10, in my opinion.

Recurring Hours Tracking

Alice needs to track her working hours. She schedules a task to track working hours every weekday when done. She knows that she will track all missed days before marking an overdue instance done.

She tracks her hours for today (Monday) and the next occurrence of the task is tomorrow (Tuesday). Later, she works a few more hours and tracks those (still Monday). She marks the task as complete again.

The next occurrence should still be tomorrow, not Wednesday.