Thumbs up for using the daily note date format!
3 Likes
Then I think we both are advocating for the same thing, and the thread itself has experienced a little scope creep. Using the same date trigger and date format is certainly a great idea (and, to repeat myself and others, using the daily note date format is probably the best approach for this).
My point about human-readable task strings is that if we add syntax for:
- Due dates
- Do dates
- Defer dates
- Start dates
- Reminders
- Deadlines
- Milestones
- …
…it will become very unnatural to write out tasks, and reading tasks will be even more difficult. Of course, you wouldn’t necessarily specify all of these at the same time, and they’re all valuable. But asking the user to do the work by entering a specifying syntax and then a special date format is, in my view, letting the computer slack off. We need to find better UX for that, or, even better, find ways of getting the tool to recognize and understand “natural language” (or at least “natural structure,” as illustrated by my approach using daily note structures above) with this kind of metadata.
4 Likes
Ok, it seems that this conversation is going more meta than I thought.
I think we started with the underling assumption that agreeing on a task format and date format was a good thing. Erase that.
Let’s ask the question first, Do we want a standard for dates and tasks or should every plugin go on its own because we want to promote different workflows?
2 Likes
Agreed! I do think the daily note format seems to generate the most consensus. Which leaves the triggers… 
I would think that if a task has a date in this format [[DNP]] it should be automatically treated as a due date. Or, as in Cardboard, and I think you suggest with the ##due heading, if it’s on the DNP page it should automatically treated as a due date. However, this needs to be overridden if there is an associated (due) date - I am sure I’m not the only one writing tasks on the DNP that are due in the future.
And you are absolutely right - too much syntax is a) hard to learn, and worse, b) can become hard to read (i.e. not glance-able).
1 Like
well, obviously, I am going to say YES! 
but with the caveat, that, ideally it should be optional, so as not to break existing workflows and plugin standards.
I’m a little pressed for time right now, but I wanted to throw out some thoughts I have regarding the convo so far.
The thing I would hope for is that users could wire together whatever date+task related plugins they use in a way that’s most useful to them. Going back to the original post, each of these could in theory be interoperable if they were updated to use a single format:
Kanban plugin: - task 1 @[[2021-11-01]]
Tasks plugin: - task 12021-11-1
Reminders: - task 1 ([[2021-11-01]] 8:35)
Cardboard: - task 1 @due (2021-11-01)
So, specifically speaking to interoperability: it would be helpful to have a common format that is easily parsed by JavaScript and isn’t cumbersome to type by users (even better if the users get help from plugin devs).
It’s also come up that assigning meaning to dates is useful to people. Eg. due, scheduled, completed. But these aren’t things that can be truly interoperable across all plugins. And if something like @due is required in the format, than it could be a pain for non-english users.
Also, daily notes are baked into obsidian (as a plugin), so the format is relatively universal (even with the plugin turned off). But folks who don’t use daily notes might not want to use links to define dates.
From all this, we could define a fairly simple format like (this is just an example, not a suggestion):
Using daily note links:
<user defined label>:: [[<daily note date format>|<daily note date format with time>]]
Not using daily note links:
<user defined label>:: {{<daily note date format with time>}}
Both of these formats could be parsed by a single regular expression.
Using this format, the Kanban plugin can support 🎃:: [[2021-11-02]] or due:: {{2021-11-02 3:25 pm}} or whatever the user wants. But maybe the Cardboard plugin ONLY supports due:: {{2021-11-02 3:25 pm}} because that’s the only meaningful label in the context of the plugin. It would be up to the user at this point to wire things up according to their needs, but they’d be enabled to do so by the common format.
The last thing that comes to mind is that all of this only really makes sense in terms of task lists (- [ ] Hi, I'm a markdown task) because markdown tasks can be easily gathered from obsidian and dataview’s api, and are pre-defined as “tasks”. This gives plugins a common source of data with at least some shared understanding of what that data is. When we move outside of task lists, I think things get too vague for meaningful (or easy) interoperability
9 Likes
I agree that this is dual problem of dates and meaning associated with the dates.
I agree with this proposal.
I think in the context of tasks having a shared understanding of this
do:: [[2021-11-02|2021-11-02 3:25pm]]
do:: {{2021-11-02 3:25pm}}
and
due:: [[2021-11-02|2021-11-02 3:25pm]]
due:: {{2021-11-02 3:25pm}}
would be an awesome great first step.
Having user defined labels would be nice, but I think will make things harder.
Another point is that while daily notes can provide a standard for dates, it doesn’t define one for times.
This, as far as I understand, all sounds really great!
am I right in understanding that what makes the parsing possible is the ‘::’? and that’s why the user defined label is not as important, and could be an emoji or a word that makes sense to the user (e.g. do, due, scheduled, etc)? or is it the label itself?
and yes, absolutely for the task lists!
I would also say that I think it is fine for different plugins to have different functions - that is some might not support the idea of scheduled or defer, while others do. If there is a daily notes page link in the date itself, at least it would still show up in the backlinks, or could be found through a search query. so, I don’t think it’s necessarily the label (e.g. do, due, etc), but whatever symbol or string (e.g. @, ~, +, $, *, ::, etc) that triggers the parsing of “there’s a date (and possibly time) following this trigger.”
Does that make sense? I’m finding it hard to express what I am thinking, given that I don’t know how any of this works on a technical level…
Sort of. The Dataview plugin can index and display values listed in the front matter of our notes.
If we were to list the information in the note body, by writing field:: "value" Dataview indexes it as if was written with the rest of the metadata. Quite useful to decluster information around.
What here is being discussed, at least initially is that neither field nor how value are to be written is standarized accross Obsidian (except Daily note template standards), making it really hard for plugins to develop proper symbiosis. I.e: Writting notes in Kanban and getting the Tasks plugin to index them.
Many syntaxes are possible. :: Is the one data view uses already and is not colliding with other stuff.
sorry, I meant in @mgmeyers example:
I was wondering whether , in this example, it’s the double-colon that signifies the date to be parsed is following (as opposed to the pumpkin). That’s what I was trying to figure out. Or perhaps it is a combination of pumpkin+double-colon… 
So, this is the next step of the equation. Like you mention, :: followed by the specified date format ([[...]] or {{...}}) is one way we can narrow down the amount of work we have to do to detect these dates, and detecting what’s before :: also serves as an easy way to detect the date’s label.
To put it in pseudo code, we could say something along the lines of:
- Detect 1 or more non-space characters followed by two colons, make this the label
- After that, look for 0 or more spaces followed by square or curly brackets
- Grab everything else until the corresponding closing brackets, make this the date (if it’s in the correct date format)
The problem with this is that it’s not very efficient. We’d also have to look at things like link-to-page:: [[My Page]] just to verify that it doesn’t match what we’re looking for.
The more unique we can make our formatting, the faster it will be to parse. So, even something like this would make our lives easier @due:: [[2021-11-02]] because now we can change the first bullet above to:
- Detect 1
@character followed by 1 or more non-space characters followed by two colons, make this the label
This means we can skip all words that don’t begin with @. The other benefit of having some special character is that it can help users see that these key/value combos have unique meaning in relation to other dataview metadata.
Does this help clarify what you were asking?
3 Likes
Thank you for explaining this in such detail, this all seems to make sense!
Now, how do we a) agree on a standard and b) get it implemented? 
In other words…make this happen?
I’d love to be helpful, but to some degree I feel that for many reasons the decision is with you, the plugin developers, as you’re the ones having to do extra work…(sorry!), and to make it fit with the way your plugin is already working (in other words, you know the limitations/possibilities).
I can only speak for myself, but I personally really like your earlier proposal (the one including the pumpkin).
thanks for engaging with this discussion and being open to the various ideas presented here!
One request I have is that for people with simpler task management needs like myself, where I don’t want to have all these different forms of dates, is that if no @due:: for example provided and just a [[2021-11-07]] date page link (at very end of task for parsing sakes) for example, then it’s assumed to be the due date. I just don’t want to have to take the time to write out each time due::() for example.
3 Likes
Is there any reason not to go wild with unicode here? Instead of a conventional symbol like @?
I suppose the character should be easily typed. I also imagine these characters won’t render on all devices or typefaces.
E.g., Bamum script can be quite fun:
𖠷
𖤘
𖡺
𖤂
𖦏
𖠱
Yes - what is Unicode? Im only being half-facetious, but that’s the kind of thing that makes it complicated for users who don’t know certain terminology or even things as simple as “how do I get to type this emoji on my computer?” (See above)
I also really like the simplicity of @smurfman111 ’s suggestion! Together with @rupert’s use of “if it is on a DNP then this is the due date unless told otherwise” this makes for a very clean and simple start.
So, perhaps:
-
if task and is on DNP and has no other date associated with it, use DNP date as due date
-
If task and has [[date]] at very end of task, interpret [[date] as “due”
For ‘advanced’ scheduling options, such as do, start, defer, etc some options:
- task @start:: [[DNP]]
- task ([[DNP]] start)
- brackets would allow time to be added ([[DNP]] 15:15)
- task start:: {{[[DNP]] 15:15}}
- task ;;start [[DNP]] 15:15;;
I’m sure there are many other ways, I think the simpler to read and write(!) (eg make use of Natural Language plugin) the better!
1 Like
There’s good reason not to use a symbol like @ though: it’s used elsewhere often. I would really discourage its use here! Doubtless it would cause conflicts.
3 Likes
Ok!
How about
~ (or ~~)
‘+ (or ++)’
= (or ==)
I’m sure all of these will be problematic for some (especially those who do anything math related, hence the double-version)
The double-colon with text seems otherwise the cleanest to me
Start:: [[DNP]]
Alternatively wrapping the entire string in
Brackets or semi-colons?
Do you have any alternative suggestions?
Could you expand on this? I’m curious where you anticipate conflicts with @.
One thing to keep in mind is that, with the example above we’d be looking for several key pieces of structure: @___:: [[___]]. In theory, this is a pretty unique structure, unless dataview users prefix their keys with @.
One thing that’s nice about @ is its meaning (at). So we can say, a thing is due @ this day and time, or completed @ this other day and time. on would be more appropriate for dates without times, but at is still pretty close.
Another thing that’s nice about it is that it’s easy to type, and can serve as a trigger for a date/time selector (like the NL dates plugin does). In this case, it wouldn’t conflict with email addresses, because our trigger would be <space or beginning of line>@.
Just to be clear, I’m not suggesting @ is the best symbol, more that I’m curious if there’s something I haven’t thought through here.
Some other easily accessible options could be:
!due: [[2020-11-02]]
+due: [[2020-11-02]]
&due: [[2020-11-02]]
?due: [[2020-11-02]]
~due: [[2020-11-02]]
%due: [[2020-11-02]]
Also, if we didn’t have a special at the beginning, it would be difficult to offer some sort of date autocomplete (a la Kanban / NL dates)
2 Likes
There are two things I see that are tricky about this:
- I think we’d have to parse every link in every task to determine if it’s a date, which could potentially slow things down
- This format could lead to false positives if someone wants to link to a DNP for some other reason then it being considered the due date. Eg,
- [ ] Process left over TODOs from [[2021-11-02]]
The Kanban plugin handles this ambiguity by requiring a user definable symbol in front of meaningful dates (@ by default): @[[2021-11-02]]. The plugin doesn’t assign any meaning to dates though, so their meaning is left up to user interpretation. So:
- [ ] Symposium title and description @[[2021-11-04]]
Becomes:
1 Like