Due date issue with tasks created using 'Relative' due dates in Filter bar about sleek HOT 12 OPEN

What is happening is a side-effect of the changes made in 1.2.2 to try to avoid re-ordering the tags in a todo. In 1.2.2 and later versions, sleek is saving the "raw" string rather than the string generated by toString. That means that in 1.2.1 it would change due:1d into due:2022-10-23 but in 1.2.2, it keeps the raw string that you typed when you added the todo, which is stored in the file as due:1d. The meaning of that relative date will change as today's date changes.

WORKAROUND: if you force it to run editTodo instead of addTodo it will reformat with toString and not use the raw string. An easy way to do this is to tap the recurrence picker, select no recurrence, and the due date will change to an absolute ISO date string.

@ransome1: If addTodo did the same toString thing as editTodo, that might solve the problem, but I'm not sure whether addTodo is used for other things than just adding a todo interactively. If so, perhaps it could have an option to reformat instead of keeping the raw string, and then use the reformat option when calling it to add interactively?

The other issue which was noted by @CPUGPU is that due:d doesn't behave like due:1d as one might expect. I have a fix for that. But it won't do much good until we fix the main issue described above.

from sleek.

@CPUGPU @TriggerDingus thanks for reporting this.

@zerodat well analysed. There is progress on jsTodoTxt (jmhobbs/jsTodoTxt#33), the library that parses the string into a todo.txt object. The author is implementing the option of not altering the input string during parsing. Once this is published I can remove the ugly raw workaround and many issues, including this one, will hopefully be resolved.

@zerodat I propose we don't work on this issue until the new jsTodoTxt release comes around.

from sleek.

@TriggerDingus i didn't close it on purpose, I think it got closed with the latest release, seems to be some GitHub automation. I'll reopen.

from sleek.

Just some more documentation on this. I created the following task on 10/19/2020 using the Filter bar to create the task and a due date of "due:1d". As you can see, as I post this the date today is 10/20/22 but the task keeps getting pushed to one day from today as the days pass, so it doesn't come due.

Here is the task text:

from sleek.

Have you tried due:d without the 1?

It's a little fuzzy in the wiki, but it appears for single values the "1" is omitted. Still probably should be evaluated, but worth a try without it.

from sleek.

The issue exists for ANY tasks created with relative dates. For example, I have tasks created using "due:monday" that get pushed every monday to the following monday, hence, never coming due. I have others created using "due:2w" that are pushed two weeks each time they should be coming due. I'm avoiding using relative dates until further notice since I'm missing tasks that should be coming due.

from sleek.

I think there is some mixing of recurring date format with due date a little bit.
Due dates should be in ISO-8601 format: YYYY-MM-DD

Sleek has some "friendly" date parsing that relaxes that rule a bit courtesy of the Sugar library. The problem may be there or in the way Sleek uses the output from Sugar.

Testing (1.2.8 appimage on xubuntu 20.04 LTS) reveals some inconsistent results:

• due:d doesn't give the task a due date.
• due:1d results in task due tomorrow.
• due:2d due date in 2 days.
• due:w no due date.
• due:1w results in a due date 1 week from today.
• due:m no due date.
• due:1m due date in one month.
• due:saturday due date tomorrow

I'm leaving the "1d", "2d", and "saturday" tasks as-is and will see if they work.
You may want to test using ISO-8601 format just to verify that behaves as expected.

from sleek.

I understand what Recurring is since I use the feature heavily, but that isn't there my issue is. I probably have about 25 recurring tasks and they are fine.
The ISO date works fine and always has for me - I've had to go in and manually find and convert all me recent tasks to use ISO due dates since anything I created with relative due dates are not coming due.
As I describe, the issue is that using relative dates no longer seems to convert them to the ISO date upon creation. Task items I created a long while back work fine and seem to have been converted to ISO date when I created them using a relative date. New ones created with relative dates are not converted to the ISO date and so never come due. This has nothing to do with Recurring items.

from sleek.

Bug confirmed. Due dates of the test tasks created yesterday moved.

• due:1d created yesterday now shows due tomorrow instead of today.
• due:2d now shows due 10-24 instead of Sunday 10-23.
• due:1m now due 11-22 when it should be 11-21.
• due:saturday now due next Saturday instead of today.

Also appears there is another bug: Can't delete the tasks. :(

from sleek.

Per your request, I tested the following after you dropped v1.2.9:

Created a task "due:Today". The following day, the task had crept forward by a day.
Created a task "due:1d". The following day, the task had crept forward by a day.
Created a task "due:3d". The following day, the task had crept forward by a day.

When I open any of these tasks, it is still storing the relative due date instead of the standard date which I think is the problem?

from sleek.

Yes, I speculate that this is still due to the raw string being stored rather than the result of toString. @TriggerDingus could you try the workaround of clicking the Recurrence chooser? You can just choose "No Recurrence", but in my tests, that was enough to make it go through a different code path which stores the absolute date rather than storing the relative date.

from sleek.

Yes, I speculate that this is still due to the raw string being stored rather than the result of toString. @TriggerDingus could you try the workaround of clicking the Recurrence chooser? You can just choose "No Recurrence", but in my tests, that was enough to make it go through a different code path which stores the absolute date rather than storing the relative date.

I've been using only absolute dates as the workaround until this bug is resolved. Thanks though!

@ransome1 closed this bug, so I'm wondering if he/she thinks it's resolved?

from sleek.