Open Piscean opened 6 years ago
If you have Work item due:2018-01-03 With added text.
, it will sort "correctly". The period makes it sort "incorrectly" because the due date is no longer recognised, so it's sorted as if it has no due date.
Quotes because I believe the spec says the date must be followed by a space, making this intended behavior. I do think it would be reasonable to change, though, so that trailing punctuation does not invalidate the date (I think trailing letters still should); ultimately it's @mpcjanssen's decision.
Oh, interesting. I haven't read the spec, but if it's working the way it's supposed to, then not to worry. It's just different behavior from the Windows todotxt.net app so I thought I'd flag it.
Technically, due:
is an extension of the spec, which includes a section on how extensions are defined (using key:value
pairs). So, our due:
extension can have whatever behavior it wants and still be compliant.
However, the original todo.sh tool included support for addons, and extensions supported by those addons (including due:
) have become de facto standards, so if we did allow trailing punctuation, other tools would likely not be able to parse the date.
Thus, either decision is reasonable. My personal preference is not to be held back by a legacy implementation (especially since supporting this does not mean we should ever intentionally place a period after the date, only that we should still parse it if one exists, although that does entail some weird stuff in how we handle this in lua). But, compatibility is also a good thing, so I'll stand by whatever decision @mpcjanssen makes.
I would prefer to accept 'obvious' stuff like due:20171212.
but to make sure to never emit such a thing when using the UI to set dates.
I will take this into account when redoing Task.kt
There is no real reason to check the character after any date as long as the date is YYYY-MM-DD
. Will change this behavior.
Hmm, less easy than expected because of the way the parser tokenizes.
Then close this issue. The ending '.' is caused by the keyboard, and was only because I went back to edit something. It's not a common case, and no data was lost. (I just couldn't find it.)
@Piscean I still would like this to work so not closing the issue yet. Just handling it with lower prio.
Repro:
"due:2018-01-03." should sort the same as "due:2018-0103"