Task management devs - define a shared date and action format

[WhiteNoise]

Thank you for your feedback. I agree with your points.

As I mentioned in my previous post, I understand that “standardize on letting users customize everything” (including the signifiers) imposes an unbearable burden on plugin developers up to the point that this should be handled by core Obsidian and accessed through APIs by plugins. This aside from making document hard to parse outside Obsidian.

I agree that plugins should be able to parse any sensible date format (using js library) and only the creation of new dates should default to the current daily note format (or at very least have the option to follow it).

Here’s a lightweight idea. Follow this pattern:
do:: {a date format} {a time format}
do:: [[{a date format}]] {a time format}
Time is optional.

Where {a date format} and {a time format} are whatever is parsable by the major js libraries (say momentjs that is bundled in obsidian).
On creation of a new do date or due date for a task, any said date and/or time is valid. However, all GUI assisted date picker must have an option to follow the daily notes format for dates.

[mgmeyers]

Thanks for your input here!

@schemar

Tasks will support a list of date formats, but Tasks will not support user defined formats.

Totally agree with the sentiment. The tricky part is that to support links to daily notes, we’d have to support a user defined format that could change at any time without a 3rd party plugin being notified.

@schemar

The same is true for “signifiers” like due:: or . I am happy to support a list of those including a standardized due:: (or whatever we end up using), but Tasks will not support user-defined signifiers/labels. As a side note, the semantic information of due vs. scheduled is important to the tasks plugin and not only to the user. Tasks must know which label belongs to which date.

Yes, exactly. The suggestion I offered here isn’t that users should be able to arbitrarily define labels (though for some plugins this may be appropriate), but that the labels are a contracts between users and plugin developers. Plugin developers would define labels that are meaningful in the context of their plugin, and users would choose which labels to use accordingly. Using the standard format would then increase the chances of interoperability between plugins. Defining some standard labels could improve these chances even more, but at the end of the day, some plugins just won’t be compatible, and that’s ok, too.

[WhiteNoise]

@mgmeyers

Totally agree with the sentiment. The tricky part is that to support links to daily notes, we’d have to support a user defined format that could change at any time without a 3rd party plugin being notified.

I believe that as long as the date format chosen for daily notes is something that momentjs can digest, we should be fine.

[mgmeyers]

Hmm, interesting. From my understanding, I thought you have to tell moment the format of the date you’re telling it to parse.

I see the docs say:

For consistent results parsing anything other than ISO 8601 strings, you should use String + Format.

It looks like the default daily note format can be parsed without hints, so that’s something.

Interestingly, you can also supply a list of formats to try. This could be handy if the user did change format and we knew about it somehow.

I’ll play around with it and see how forgiving moment can be.

[WhiteNoise]

perhaps it would help this whole discussione if we impose restrictions on the daily note format.

[Kabo]

@mgmeyers

that the labels are a contracts between users and plugin developers. Plugin developers would define labels that are meaningful in the context of their plugin, and users would choose which labels to use accordingly. Using the standard format would then increase the chances of interoperability between plugins. Defining some standard labels could improve these chances even more, but at the end of the day, some plugins just won’t be compatible, and that’s ok, too.

Ah, I see - I thought that it would be simple enough to exchange the signifier before the :: making it easy to make the different plugins work with each other.

But if that is not desirable, then we would need to also agree on a list of useful signifiers. I’m going to suggest a list with aiming for what seems to be common, and simple:

Basic:

• due
• do (or start)

Optional (but probably quite desirable):

• scheduled
• defer
• start (or do whichever doesn’t make it into basic)

I’ll leave the dates discussion to you as it seems to be getting technical with momentjs etc. I’d just reiterate that it should work with the DNP format, and be natural language compatible (‘next Friday’).

Thanks all for engaging in the discussion and being willing to work on this!

[dylan_k]

I’m all for a standard format. ISO 8601 seems to already be the common format for the dates themselves. I’d vote for markup around those dates to be as minimal as possible, for easiest typing.

[veradrawer]

What is the current state of implementation?

I’m wondering if us users can help in any regard.

[schemar]

We need to make a decision and then devs can start implementing it. Not sure how to drive this to the end „community style“ with no one having real power/responsibilities.

Does anyone disagree with what @WhiteNoise proposed?

@WhiteNoise

do:: {a date format} {a time format}
do:: [[{a date format}]] {a time format}

With due, do, starts, done and a default date of [[YYYY-MM-DD]]? With time being optional.

I just realized the semantics are not aligned. In my example, do is equal to scheduled. And start is equal to blocked until.

[Kabo]

Looks good to me!

Just to be extra-clear, it would be:

do:: [[{a date format}]] {a time format}

- [ ] task1 due:: [[2021-10-01]] 10:15

Is that correct?

If so, I am all for it!

What is the effect of scheduled and blocked until in a practical example?
Or is it more conceptual, but does not have an effect on, say, a query (e.g. cannot show blocked until until the actual day is reached)?

[shabegom]

I don’t have much to add that hasn’t been said, but I’d lean towards flexibility for user to define over presets. If there was a core “tasks” plugin that allowed for these settings and other plugins could read that would make it…easier?

One point, you can support arbitrary date formats using moment:

moment(date, dateFormat)

moment("1984-11-05", "YYYY-MM-DD")

moment("Jan 10, 2021","MMM DD, YYYY")

The challenge I believe is that if the user can change their date format at any time, what happens to all the previous dates in the old format? Do we need to update them all?

If we could include these due,do,done dates as a core plugin and integrate into the metadataCache…

Anyways, I like standardizing dates in plugins. Good convo!

[schemar]

Yes, in my opinion it would be like you said. For example:

- [ ] Mow the lawn due:: [[2021-12-31]] do:: [[2021-12-21]] start:: [[2021-12-01]]

The difference between „scheduled“ and „blocked until“: „scheduled“ means you plan to work on a task on a certain day. You may want to see the task also the days before, because you could do it earlier and get it done if you have the time. „Blocked until“ means you cannot work on the task before that date. That means you do not want to see the task in your list of tasks before that date.

[Kabo]

Thanks for the explanation, makes perfect sense!

[kurtharriger]

How about putting metadata under the task?
Putting a bunch of metadata on the same line as the task causes a lot of line noise.

- [ ] Watch Required Training Videos
  - due:: [[2021-11-30]]
  - do:: [[2021-11-19]]

[kurtharriger]

Actually better idea, maybe use add a block ref to the task and then store metadata in yaml. Not only is metadata then structured content stored in the same file, it wont clutter the rendered output.

[flatline]

Hi all, apologies for being late to this discussion. I love the direction that this idea is taking but I have one flag - Obsidian forbids *"\/:|? in filenames. I might be in the minority here, but I use @schemar’s tasks daily to organise my meetings. A common use case is this:

- [ ] 11:00 [[1-1 Jonathan 📅 2021-11-21]]

I will then put all of my meeting notes inside that note, along with any tasks and reminders for the next meeting.

The date format provided by tasks is really helpful for me in this context, as it differentiates all of these 1-1s into atomic notes.

If we were to replace the current format with due, i.e.

- [ ] 11:00 [[1-1 Jonathan due:: 2021-11-21]]

it would definitely break my workflow, as Obsidian doesn’t permit : in filenames.

Enabling users to select their preferred key::value pair format from a prefabricated list, per @mgmeyers’ suggestion here, would solve this issue. So:

- [ ] 11:00 [[1-1 Jonathan due:: 2021-11-21]] (not allowed)

could become:

- [ ] 11:00 [[1-1 Jonathan +due 2021-11-21]]

[WhiteNoise]

I have spent some time reviewing all the task management plugins to get a better grasp of the issues. All the plugins implement different workflows (sometimes major, sometimes minor differences) and I agree with @ryanjamurphy that we should preserve this and not force all plugins to do the same thing.

The common thread for tasks is a definition of a date and meaning associated to that date.
For the date, I saw that all of you pretty much used ISO 8601 so I would stick with it. And if the user wants interoperability with daily notes, they are gonna have to use ISO 8601 for daily notes as well. Amen.

Regarding the tags, let’s just pick a few that we all agree on the meaning.

We could have something like

due:: 2020-12-01
do:: 2020-12-01

and if the user wants to link to the daily note explicitly

due:: [[2020-12-01]]
do:: [[2020-12-01]]

[mgmeyers]

@WhiteNoise in this case, plugin authors could adhere to dataview’s existing api for task metadata: Data Annotation - Dataview

Dataview currently supports due::, created::, and completion::.

This won’t work for my needs in the Kanban plugin, though. For example, supporting arbitrary daily note and time formats is a hard requirement. In general, everything outlined in this doc would need to be considered: Obsidian Plugin Task+Date Format · GitHub

[WhiteNoise]

@mgmeyers

This won’t work for my needs in the Kanban plugin, though. For example, supporting arbitrary daily note and time formats is a hard requirement. In general, everything outlined in this doc would need to be considered: Obsidian Plugin Task+Date Format · GitHub

Yeah, so basically in my last post I was suggesting to give up this hard requirement (arbitrary daily notes format). And everybody sticks to ISO 8601 and if the user wants interoperability with daily notes, they should also stick with ISO 8601 as daily notes format.

I am trying to reduce the number of moving parts.