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.
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.
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.
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!
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.
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?
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.
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)?
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!
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.
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.
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)
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
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
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.
