threshold duedate recurring

[J70P]

I played around with threshold- and duedates with recurring.

Let's give an example

foo t:2015-10-13 due:2015-10-16 rec:1w

If I complete this task today (2015-10-16), a new one will be created

foo t:2015-10-23 due:2015-10-23 rec:1w

I would have expected the new one to preserve the 3 days diffence between threshold and duedate, like

foo t:2015-10-20 due:2015-10-23 rec:1w

[mpcjanssen]

I agree changing all dates in a task makes more sense. Currently Simpletask tries to be smart about it. This would be break compatibility with the current version though so I will need to think about how to implement it.

[mpcjanssen]

The suggested behavior is the behavior in newer versions.

[J70P]

Thanks. I installed the most recent version 7.0.9. As I tested, the behaviour has not changed since my 1st post. Have I missed something? Like a setting?

For testing I created a new task

testing t:2016-02-04 due:2016-02-07 rec:1w

Completing this task results in the new one

testing t:2016-02-14 due:2016-02-14 rec:1w

Same behaviour as before.

[mpcjanssen]

Odd, let me double check this

[smichel17]

Can confirm this bug/enhancement is still outstanding.

[FixerDave]

Confirming v9.0.1 has this issue. Completed recurring tasks get the date completed + recurrence for both the next due and threshold dates.

[Vijayanth-Reddy-K]

Erm, isn't that the intended behaviour?

Looking here, under recurrence, we see that if the recurrence pattern does not have a + sign preceding the number, the new threshold and due dates are calculated from the date of completion. Thus, a pattern of x 2017-03-25 due:some_date t:some_date rec:1w calculates the new threshold and due dates as one week from today, viz., the 25th, and this, comes up with the same date. This is because the app has no way of knowing before hand when the task is completed.

Doing so also helps counter the case where, let's say, the recurrence is 1 day, and the threshold was initially set as 1 week before the due date. In which case, completion of the task now puts the threshold date in the future (tomorrow) as against 6 days ago.

However, replacing rec:1w with rec:+1w maintains the interval between the threshold and due dates.

[amariusz]

This is old discussion but I'd like to opt for change @h-cspu was describing. I've run into this issue yesterday on Dropbox version I've downloaded in November 2020 (I've Dropbox sync issues on latest generic 'NG' version but it seems to work the same way regarding recurrence).

According to manual SimpleTask recurrence behaviour is inspired by ToPyDo.

However if you start today with @h-cspu nonstrict (rec: without +) example foo t:2015-10-13 due:2015-10-16 rec:1w you wil get: 2021-01-26 foo t:2021-01-30 due:2021-02-02 rec:1w in ToPyDo and foo t:2021-02-02 due:2021-02-02 rec:1w in SimpleTask. (NOTE: SimpleTask is not adding creation date in this case even though 'Datestamp new tasks' is checked'. I guess it's a bug.)

In this example SimpleTask just adds 1 week offset to todays date and places it in both t: (start date) and due: (due date).

ToPyDo on the other hand first calculates how many days before due date task should appear on the list. Length is 3 days in this example (old due date - old start date). Then it sets due date as todays date + 1w (as SimpleTask). Finally start date (t:) is set as due date minus lenght. In my opion that's the bevaiour this issue is all about.

I like the example from ToPyDo docs so here's another one to complement 'foo': https://cdn.rawgit.com/bram85/topydo/master/docs/index.html#Recurrence

starting with Water flowers t:2021-01-01 due:2021-01-05 rec:2w

as of today you will get on completion x 2021-01-26 Water flowers t:2021-01-01 due:2021-01-05 rec:2w 2021-01-26 Water flowers t:2021-02-05 due:2021-02-09 rec:2w This item will appear on the list in 10 days, due in 2 weeks. Note that recurrence period should probably be longer then task's visibility period - otherwise task will be visible all the time.

I can't imagine in which real-life scenario SimpleTask behaviour would be more useful. On each recurrence information about start date / due date offset is just lost.

You can check topydo implementation here: https://github.com/topydo/topydo/blob/master/topydo/lib/Recurrence.py

However there is one difference in SimpleTask's behaviour that I like better than ToPyDo's (both in strict and nonstrict modes). SimpleTask allows you to have entries with start date (t:) only (or even without it - just rec:) and new entries are kept that way. ToPyDo doesn't handle this case very well - it always adds due date that defaults to today and then attempts to calculate lenght anyway which is not useful. Related ToPyDo issue

Right now ToPyDo and Simpletask share common behaviour in three cases:

• strict mode
  • both t: and due: present (t: < due:)
  • only due: present
• nonstrict mode
  • only due: present

BTW I don't understand @Vijayanth-Reddy-K argument:

This is because the app has no way of knowing before hand when the task is completed.

Thanks for great app, Mariusz