Creation date must be specified if completion date is

[callegar]

Is it an actual bug?

I believe that sleek intends to be compatible with the todo.txt syntax. If so, this is a bug.

Did you check if the bug has already been reported?

Checked

Describe the bug

The todo.txt specification found on https://github.com/todotxt/todo.txt says that creation date must be specified if completion date is. See the following illustration:

To Reproduce Steps to reproduce the behavior:

1. Add a task
2. Mark it as completed
3. A completion date is added, but no creation date is there.

Do you see any error entries in sleeks developer tools?

N/A

Expected behavior

When creating a task, sleek should add a creation date, so that when the task is marked as completed the creation date is there together with the completion date.

Screenshots

N/A

Desktop (please complete the following information):

• OS: Linux, manjaro and ubuntu 22.04 (flatpak client)
• Version of sleek 1.3.1
• Source: Flathub

[aubreyz]

I definitely don't want creation dates imposed on me.

Can you not add a creation date if you want that: https://github.com/ransome1/sleek/wiki/Hidden-preferences,-custom-variables-and-command-line-parameters#append-start-date-on-todo-creation

[callegar]

If there is a specification for the todo.txt format, then IMHO sleek should have a default behavior consistent with it. I understand that using a dialect of the todo.txt specification may be convenient, but probably should not be the default. I also understand that the specification itself is rather ambiguous (as illustrated in https://github.com/todotxt/todo.txt/issues/70) and that de facto standards exist possibly deviating from the specs, but ignoring the spec will not help it become more robust and correct.

Furthermore, the wiki seems wrong in saying that "per default sleek will append a start date". The opposite appears to be true. And setting appendStartDate to true does not seem to have any effect.

[aubreyz]

Yes but the spec is not that there has to be a creation date. It is up to the user to have created a creation date if they want a later want a completion date. So not making a creation date is consistent with the spec.

[callegar]

In this case, sleek should not write a completion date, but currently it does unconditionally. If there is no creation date and no completion date, the possibility of setting recurrence should also be disabled, I think.

[aubreyz]

Fair enough. The spec does seem odd though - I cannot see why a completion date should not be permitted if there is no creation date -- that seems completely arbitrary and unnecessary.

[callegar]

that seems completely arbitrary and unnecessary

I think that it is because otherwise having a single date it would be impossible to know if it is a creation date or a completion date.

The spec does seem odd though

Main problem is that the "visual" spec (the image) is at times in contradiction wit the "textual" spec.

[clach04]

I agree, the image contradicts the text. I believe the text file is clear on the rules for dates and should be used as primary source, see https://github.com/todotxt/todo.txt#rule-2-the-date-of-completion-appears-directly-after-the-x-separated-by-a-space

• Completion dates are required
• Creation dates are optional

[callegar]

You are probably right, but English text is not the best tool to specify a formal grammar and is always going to be ambiguous and subject to some interpretation (e.g. would a tool only using the key:value format and never the parenthesis based notation to express priority be within the golden standard? If in a non completed task I specify a priority with (...) and then again with pri:.. is it OK? And if they do not agree?).

The very conclusion "completion dates are required, creation dates are optional" appears a quite reasonable extrapolation from the text, but the text never says so explicitly :-(

I fear that with this loose specification there are always going to multiple not fully interoperable dialects of todo.txt. Maybe, at least formalizing one and giving a name to it could be a good thing (just like people caring about correct interoperability refer to "GitHub Markdown " or "CommonMark Markdown" or "Pandoc Markdown", because Markdown... https://babelmark.github.io/faq/#what-is-this-for)

Personally, I would like to have the creation dates for tasks, because it is always easy to transform a text file removing some information, but augmenting it later to add some missing piece is impossible. It is also a pain I have to write these dates manually at every task creation, so I wish bug 474 and 401 could get fixed. It is always a matter of personal usage practice what is best, so I am totally happy about having this under an option (after it is fixed, promoting it to not being hidden would help, though).

Incidentally, I also find it rather inelegant that you need to use two different ways to specify priority depending on whether the task is completed or not. Personally I would not dislike a dialect following the original image based specification allowing x (A) 2023-05-01 ... enabled under an option.

Incidentally it seems weird that the rationale about almost every aspect of the specification seems to be natural sorting, given that this is a computer related standard, so the only important thing would be to make it easy to isolate the individual fields of the record, so that you can sort based on any field in any order with plain text manipulation tools.

[rzw]

I think that it is because otherwise having a single date it would be impossible to know if it is a creation date or a completion date.

Not really. First date after x is completion date since completion dates are required