Skip to content
This repository has been archived by the owner on Feb 13, 2024. It is now read-only.

threshold duedate recurring #312

Open
J70P opened this issue Oct 16, 2015 · 8 comments
Open

threshold duedate recurring #312

J70P opened this issue Oct 16, 2015 · 8 comments

Comments

@J70P
Copy link

J70P commented Oct 16, 2015

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
Copy link
Owner

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
Copy link
Owner

The suggested behavior is the behavior in newer versions.

@J70P
Copy link
Author

J70P commented Feb 7, 2016

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
Copy link
Owner

Odd, let me double check this

@mpcjanssen mpcjanssen reopened this Feb 7, 2016
@smichel17
Copy link
Collaborator

Can confirm this bug/enhancement is still outstanding.

@FixerDave
Copy link

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
Copy link

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
Copy link

amariusz commented Jan 26, 2021

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants