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

[zerodat]

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.

[ransome1]

@ransome1 Thank very much for making "rolling tasks" possible. It makes it unnecessary to sit down in the evening and transfer unaccomplished tasks to the next day.

The behaviour is as expected in every respect. I.e. The not converted dates of existing items in the file remain untouched when switching from false to true and entering new items.

But another very useful "exploit" of mine doesn't work anymore. I don't know if this is an intentional revision of the version 1.3.2-rc.1 which I am using or just the working model to test features. I noticed that when I hit ENTER the task was saved which made me curious because it was CTRL+ENTER in the current release.

Until now it was possible (in sleek!) to structure Tasks as easy to read notes. ENTER and SHIFT+ENTER were translated to DLE (data link escape; ALT+016 in CP1252) which created a new line in the editor. I know it's stretching the todo.txt syntax a bit but it's still one line when you open the todo.txt in notepad++ so conform to the norm. PLEASE hold on to ENTER/DLE for a new line in the editor pop up window!

The latest developer preview is a complete rewrite of sleek (#501). Many features are still not implemented, among those is the text area function, which contains the multi line creation of todos.

[ransome1]

@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.

[ransome1]

@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.

[rzw]

As I experienced it "this is due:today" or "this is due:0d" stays exactly this way when saved. So even in one week this task is due "today". This doesn't seem to be 100% reliable though. It's still like this when sleek is closed and reopened, but it seems to change into an absolute date at some time or another. I couldn't reproduce it.

CPUGPU (on Oct 22, 2022) and TriggerDingus (on Nov 8, 2022) expect relative or describing dates to be converted to absolute calendar syntax (yyyy-mm-dd)

zerodat analyzed this on Oct 23, 2022 and stated that behaviour had changed:
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.

So the question is: should typing be changed before it's stored in the file (like in version 1.2.1)

My personal opinion is: probably. But I certainly like these creeping or rolling tasks as well which is why I say: Have both by introducing a discriminating character like "+" to store raw text in the file and convert before storing when "+" is not present:
"This is due:+0d" vs. "This is due:0d"

PS: I didn't check latest developer preview because I'm ambivalent and don't consider it as a bug

[zerodat]

@ransome1 I think it is desirable to have the date made absolute when it is stored, because it is weird for the due dates to change only because time is passing. Something which is always due tomorrow seems kind of "fun", but not very useful in practice for most people. So if we create a task from the filter bar with something like "test task due:1d" as @TriggerDingus originally reported, then we need to have that due date converted to an absolute date in the task that is created and stored. That used to happen, but stopped happening as of 1.2.2. It might be working again in your rewrite, if you went back to the older code once the jsTodoTxt library was updated ... sorry but I haven't had a chance to test this yet.

MOST IMPORTANT: Sorry @rzw, but we should not use the syntax "due:+0d" because that already has another meaning in sleek, namely for recurrence dates which are relative to due date, not completion date. (See the "strict recurrence" section in Recurring todos (rec:) · ransome1/sleek Wiki

[zerodat]

@ransome1, I just tested in 2.0.0-dev7.AppImage. The dates shown in the UI are correct now, but unfortunately it seems that the raw dates are still saved into the todo.txt file. For instance, if I type "test task for me due:tomorrow" into the add task dialog or into the search field, and then add that task, it shows up in the UI as due:2023-09-02, but in the todo.txt file, it still says "test task for me due:tomorrow". That means that when I open sleek tomorrow, the task will have changed to due:2023-09-03. That's the bug.

[ransome1]

@ransome1 In respect to the full rewrite and the behaviour agreed upon regarding relative due dates: I now stumbled upon when a change from relative to absolute happens. Before I couldn't reproduce.

When priority is set or changed a relative due date is converted to absolute. There's no reason this should happen. (This is in 1.3.2 RC1; didn't test 2.x)

@rzw there is no further development happening in 1.x. I just double checked the behavior of 2.x and it seems to work as expected.

[TriggerDingus]

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:

[CPUGPU]

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.

[TriggerDingus]

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.

[CPUGPU]

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.

[TriggerDingus]

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.

[CPUGPU]

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. :(

[TriggerDingus]

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?

[zerodat]

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.

[TriggerDingus]

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?

[TriggerDingus]

Any news on this? I saw jsToDoTxt was updated late last year but haven't seen an update in this thread.

[github-actions]

This is an automated response. We acknowledge your report, and we appreciate your engagement. However, as there has been no recent activity in this thread, it has been marked as stale. If you have any further feedback or if the matter is still relevant, please do not hesitate to respond. Otherwise, this thread will be automatically closed in 15 days from now.

[rzw]

I acknowledge, that the expected behaviour would be a transformation from relative to absolute date upon saving. BUT I found it quite nice to have a list of more or less urgent todos to roll through the calendar until they are done. It's so easy to click on an absolute date in the calendar that I personally would prefer to leave this as it is. For me it's a feature not a bug – at least for today and tomorrow. Next week or month might be different.
Perhaps – as a feature request – one could have both along the line of recurrency and its two options (e.g. rec:3d and rec:+3d)

[ransome1]

@rzw @CPUGPU @TriggerDingus @zerodat I scrolled through the thread, but just cannot wrap my head around what the issue here is.

Could somebody please check if this issue persists in the latest developer preview? Both, jstodotxt and the recurring todo logic have been freshly implemented. Maybe it solves the issue at hand.

If not, could somebody please summarize the issue (or what's left of it) one more time?

[ransome1]

@rzw @zerodat Thanks for summarizing this.

Can a setting convertRelativeToAbsoluteDates (Default true) be a solution for this?

Scenario
On the 2023-09-02 user creates a todo with help of the dialog: Test due:tomorrow and saves it.

The default behavior (true): Relative due date is converted

• This creates a new line in the text file: Test due:2023-09-03
• Still on 2023-09-02, sleeks UI shows the due dates as 2023-09-03
• Days later on the 2023-09-11, sleeks UI shows the due date as 2023-09-03

The behavior if setting is false: Relative due date is preserved

• This creates a new line in the text file: Test due:tomorrow
• Still on 2023-09-02, sleeks UI shows the due dates as 2023-09-03
• Days later on the 2023-09-11, sleeks UI shows the due date as 2023-09-12

[zerodat]

@ransome1 that sounds fine to me. I don't think that I would ever use the false setting, but it does no harm to have it as an option if someone prefers to use it. Thank you!

[rzw]

@ransome1 Yes, thank you very much for your proposal. The default setting should be "true" since it is the expected behaviour. Then silly people like me can change this setting to "false" in order to have uncompleted tasks moved forward automatically.

Although I don't intend to switch back and forth, the setting could change after update or use of the todo.txt in a different environment. Therefore the todo.txt file as a whole should never be touched for conversion. Only when saving an item should the relative date be converted with setting "true"

[rzw]

@ransome1

MOST IMPORTANT: Sorry @rzw, but we should not use the syntax "due:+0d" because that already has another meaning in sleek, namely for recurrence dates which are relative to due date, not completion date.

I realized this. But I thought interpretation could be different depending on the prepending tag (due: vs. rec:). But coding this is probably prone to error creating unexpected results. It wouldn't be worth the hassle for a bunch of people using this.

[ransome1]

@zerodat @rzw @TriggerDingus @CPUGPU I tried to implement the two functionalities described above and merged it into the latest developer preview: https://github.com/ransome1/sleek/releases/tag/v2.0.0-dev8

Please give it a try and tell me if it works as expected. Everytime a single todo gets created or edited, any relative date found will be converted to an absolute one. In order to turn off the conversion, there is a setting.

[rzw]

@ransome1 Thank very much for making "rolling tasks" possible. It makes it unnecessary to sit down in the evening and transfer unaccomplished tasks to the next day.

The behaviour is as expected in every respect. I.e. The not converted dates of existing items in the file remain untouched when switching from false to true and entering new items.

But another very useful "exploit" of mine doesn't work anymore. I don't know if this is an intentional revision of the version 1.3.2-rc.1 which I am using or just the working model to test features. I noticed that when I hit ENTER the task was saved which made me curious because it was CTRL+ENTER in the current release.

Until now it was possible (in sleek!) to structure Tasks as easy to read notes. ENTER and SHIFT+ENTER were translated to DLE (data link escape; ALT+016 in CP1252) which created a new line in the editor. I know it's stretching the todo.txt syntax a bit but it's still one line when you open the todo.txt in notepad++ so conform to the norm. PLEASE hold on to ENTER/DLE for a new line in the editor pop up window!

[rzw]

@ransome1 In respect to the full rewrite and the behaviour agreed upon regarding relative due dates: I now stumbled upon when a change from relative to absolute happens. Before I couldn't reproduce.

When priority is set or changed a relative due date is converted to absolute. There's no reason this should happen. (This is in 1.3.2 RC1; didn't test 2.x)

[ransome1]

Since this has been implemented for a while and @TriggerDingus seems to be absent, I will close here. Feel free to re-open, in case something doesn't work as expected in 2.x

[TriggerDingus]

Since this has been implemented for a while and @TriggerDingus seems to be absent, I will close here. Feel free to re-open, in case something doesn't work as expected in 2.x

Sorry for late reply. I'll watch for the new Flapak to be deployed and give it a try. Looking forward to the new release!

[TriggerDingus]

I installed the new release via Flatpak and I found new issues with "Relative" due dates. It's partially working, but not completely.
For the record, I do have the option enabled to "Convert relative dates to absolute dates".
I found that if I create a task such as "test task due:tomorrow", it works as expected and creates a task for the following day with an absolute due date. E.G. "test task due:2023-11-03"
The issue comes when I try to create a task such as "test task due:1d" or "test task due:1w". These tasks are created with no due dates whatsoever; the due date is simply treated as part of the task description and Sleek doesn't recognize there is a due date included as a parameter. E.G. "test task due:1d" is a task added with no due date.

Here is that task, opened after created using a relative due date (note that there is no due date):

[ransome1]

Implemented are the regular dates (2023-01-01) and the options Sugar provides. Values as 1d or 1w are only being used for recurrences and have never been a requirement for due dates in sleek yet.