Creation / completion date

[jotaen]

There are basically 3 dates in the lifecycle of a todo item:

• When the item was created
• When it’s due
• When it’s completed

The most important one in practice is the due date, which is why [x]it! supports it.

I’m not sure, though, whether there should be any special syntax for the other two dates, because that would create a lot of noise. Also, a tool could still add these dates somewhere in the description text. That way, they wouldn’t be recognised or treated specially, but they would be there “for the protocol”.

[global-node]

for example:
[x] Problem Solving 1 -> 2022-03-28 #added=2022-01-01 #done=2022-03-24 tags added by tooling.
would keep the clutter low for user edited files.

[jotaen]

Yes, I’m currently also leaning towards that.

So it basically means there would be no special syntax for creation and completion, but it’s rather up the user themselves (and/or their tool) to establish a convention by using tags.

[majkinetor]

Tooling will be harder this way, its probably best to have special syntax.

[Jiehong]

@jotaen : in this case, why would the due date have a special syntax?

Actually, having a due as a tag is also clearer (it wasn't clear to me that -> meant "due"/"by"/"until"). See:

[ ] thing to do #due=2022-06-03

So, what about having tags for everything instead?

[jotaen]

Thanks for sharing your thoughts.

I think it is a bit of a “philosophical” question which properties justify having dedicated syntax, and which ones can be expressed via general-purpose mechanisms such as tags. As an extreme example, one could argue that everything can be done via tags, e.g.

Do this #status=open #priority=2 #due=2022-03-28

vs

[ ] !! Do this -> 2022-03-28

That’s contrary to the idea of a domain-specific data format, however, and it would probably be better then to use something like YAML or CSV.

In my eyes, the four properties “description”, “status”, “priority”, and “due date” are the most common and central ones for todo or check lists; so: What should be done? Is it done already? How important is it? Until when should it be done? Having a special, pre-defined syntax creates a common denominator for tools, so that they can provide consistent functionality based on these properties.

Of course, one could make the point that creation and completion dates are important as well (or any other property). I think in the end there is no sharp line to be drawn, and to a certain degree it’s also a matter of preference and personal workflows.

For the tags, I think it’s important to not restrict them in any way by assigning special functionality to some of them. These pre-defined tags would also have to be learned by users. I rather see value in making the tag space completely free and unrestricted, to give users maximum flexibility to extend the functionality to their own needs.

Another drawback with pre-defined tags would be that they are language-aware, so if someone writes their todo items in Norwegian or Japanese, they would be forced to fill in English tags. A symbolic notation avoids that. (But, as you pointed out, it can have it’s own problems, so there is that.)

[majkinetor]

Having tags for everything might be great alternative to shorter syntax.

So you could equally validly specify date with -> date or #due=date. You can never satisfy both camps anyway (verbose/terse groups of people).

[badcircle]

I think you are on point with leaving Due Date as the main, supported glyphed date, and leaving other dates up to users and tools via tags.

[majkinetor]

I prefer another syntax for dates. People can always use tags if they want anyway.

Some ideas:

Ordered as startDate, dueDate, resolveDate

[ ] Task 1   >2022-01-01 <2022-03-05 =2022-01-03

[ ] Task 2   +2022-01-01 -2022-03-05 *2022-01-01

[ ] Task 3   -> 2022-01-01, 2022-03-05, 2022-01-03
[ ] Task 3   -> ,,2022-01-03

[ ] Task 4   (2022-01-01, 2022-03-05, 2022-01-03)     
[ ] Task 4   (,,2022-01-03) 

Ordered as resolveDate, startDate, dueDate may have more sense for syntax 3 & 4:

This variant would be most compatible

[ ] Task 3   -> 2022-03-01,,2022-03-05

In this case start date is missing and resolveDate is first.

I honestly like the first one the best:

[ ] Task 1   >2022-01-01 <2022-03-05 =2022-01-03

Reasons:

1. Its semantically correct - task dedicated time must be greater then >startDate, lower then <dueDate and is resolved/equals =resolveDate (or it could be bang - !resolveDate). Similar observation is there for +-* - creation is usually signified with + symbol, finishing with -. I like ><= more tho as it seems to be easier to visualize.
2. It allows to skip dates you don't need simply by not adding them
3. It has fewer number of symbols then -> - 1 vs 3 - and is less error prone as you don't need to have space.
4. Plugins can easily inject and recognize such dates and its very unlikely such constructs naturally appear in task body.

[delfiin]

Really interesting idea >2022-01-01 <2022-03-05 =2022-01-03

[jotaen]

@majkinetor cool, thanks for writing up and sharing your ideas!

I agree, if creation, start and/or complete date were added, they should each have their own prefix, so that they can be all optional, and appear in any order.

[NiloCK]

People can always use tags if they want anyway.

This is a good point.

Reasons:
3. It has fewer number of symbols then -> - 1 vs 3 - and is less error prone as you don't need to have space.

This as well, I think.

[NiloCK]

Dropping in with my own two cents. I was inspired by this spec to start writing a tui for managing my own text-based todos, and I'm coming up against this issue now.

• -> yyyy-mm-dd does not obviously mean "due". In particular, due yyyy-mm-dd is the same number of keystrokes (shift counts!), just as machine readable, and much more human readable.
• due yyyy-mm-dd can abbreviate nicely: dYYYY-MM-DD
• [char][date] can generalize well, reusing syntax that is already defined in spec:
  • x[date] completed on [date]
  • ~[date] scrapped on [date]
  • @[date] begun on [date]

these [char][date] are easier to parse because of the non-space. A potential wrinkle is that c[Date] for created runs up against the not-that-uncommon abbreviation of c2016 for circa 2016. (I don't know how often people reference approximate dates from the past in their todo items.)

[jotaen]

Thanks for sharing your thoughts.

I think the mandatory space behind the -> sequence is something worth to reconsider. The difference between -> 2022-05-01 and ->2022-05-01 is rather subtle, and it might indeed be more user-friendly to allow both variants to appear. Since this is a slightly unrelated topic, I’ve opened a separate discussion for it.

Regarding the notation of the prefix (-> vs due), I think there are ups and downs either way. I see two worthwhile advantages in symbolic notation (->):

• It’s more distinct from other text: a sequence of symbols stands out a bit more compared to keywords that are regular words.
• It’s language agnostic: for people who are not so proficient in English, due might not be much clearer than ->. They would have to learn the meaning of due the same way as other people have to learn the meaning of ->. It also might look strange to see foreign words to be interspersed in description texts that are otherwise not written in English.

[ ] Blumen gießen due 2022-05-08
[ ] Auto waschen due 2022-05-11
[ ] Fenster putzen due 2022-05-18

[ ] Blumen gießen -> 2022-05-08
[ ] Auto waschen -> 2022-05-11
[ ] Fenster putzen -> 2022-05-18

I think this is a tricky issue, and it’s hard to make a call that works out for everyone. I personally have a strong preference for symbolic notation, and to me it’s also important that the file format has a consistent “philosophy” in that regard.