search

mjdescy / TodoTxtMac

TodoTxtMac is a minimalist, keyboard-driven to-do manager for Mac OS X (10.8 Mountain Lion and higher) that conforms to the todo.txt format spec.
Other
240 stars 40 forks source link

Recurring task date inconsistency #106

Closed snptrs closed 8 years ago

snptrs commented 8 years ago

There appears to be an inconsistency between how the Mac app and SwiftDo on iOS are handling due and threshold dates with the new rec: functionality. The iOS app is exhibiting expected behaviour, the Mac app is not.

Here's an example: Example task rec:+1w t:2016-04-01 due:2016-04-07

Using the "strict" + syntax, once this task is completed I would expect the newly created task to be: Example task rec:+1w t:2016-04-08 due:2016-04-14 – i.e. the dates should be one week from the previous dates. What we actually get for the new task, though, is: Example task rec:+1w t:2016-04-14 due:2016-04-14.

As far as I can see, the Mac app is disregarding the strict flag and is just using simple recurrence and setting the dates relative to completion date.

mjdescy commented 8 years ago

I'm on it. I will fix it ASAP.

snptrs commented 8 years ago

On closer inspection and having tried a bunch of different test tasks, it appears that what's happening is the due date is actually being moved properly according to whether or not the strict flag is used. I think, also, that when the strict flag is not used, and there are both due and threshold dates, both get moved correctly.

The issue seems to be with threshold dates and the strict option. For a task which has a due date and a threshold date, and which is set to recur with the strict option, the threshold date is set to the same as the due date, even if they were different on the original task.

Also (and this may be intended behaviour), when a task which has a threshold but not a due date is set to recur, it is given a due date in the new occurrence. I would have expected the behaviour to be that the new instance would set either a due or a threshold date or both depending on what the original task had.

mjdescy commented 8 years ago

Thanks, @therealsp.

I found a bug in which the wrong calculation is made for the threshold date when the original task has a threshold date and recurrence is strict.

Setting a due date for a new recurring task when there is no due date in the original task is intentional. I thought that the due date was the primary driver of recurrence.

Another intentional behavior you might uncover is that, if the threshold date is after the due date, the new recurring task will have a threshold date equal to the due date. That's because it doesn't make sense to set threshold date after the due date for future tasks.