Unspecific dates/scopes like W04 for Week 4, M02 for February (closed as scope too large for one request)

[Kongolan]

⚠️ Please check that this feature request hasn't been suggested before.

• [X] I searched previous Ideas in Discussions didn't find any similar feature requests.
• [X] I searched previous Issues didn't find any similar feature requests.

🔖 Feature description

It takes too much cognitive load to choose a specific day and set a date for it. When you don't know if you want to do it exactly on this day. Also you get overdue pretty quickly, when you just want to tackle 20 tasks this week, but you don't know on which day you do most.

Some people use other system, like weekly to-dos, which gives a little more freedom in execution. The idea centeres around a system, where you start moving tasks that should be done THIS MONTH first with M02 (February). Then you think this monthly task is dealt with NEXT WEEEK (W05) and later, I might choose a specific day or just leave it at this week.

Alternatively I would use a system with Tags like #thisWEEK or #nextMONTH to categorize like this.

✔️ Solution

We can use new scopes with the letters M and W for month and week. The system needs to support non specific dates now, like week 11, instead of full date stampes. This should be a huge but managable overhaul in my opinion.

❓ Alternatives

Right now searching for tasks in this week and not in a day scope is possible. But you have to use exact timestamps of days. There is no alternative besides using a completly other system like tags or a different tasks manager plugin.

📝 Additional Context

No response

[claremacrae]

Hi @Kongolan, this sounds really interesting. Thank you for writing it up.

I am missing something fairly fundamental. Which aspect of Tasks are you thinking this would appear in?

Are you thinking it would apply to the date values in individual tasks (like due dates)? In which case, they would become due ranges, not due dates.

Or are you thinking it would apply to queries?

I think others have suggested alternative ideas like making it easy to bump tasks over from one day or week to the next.

This should be a huge but managable overhaul in my opinion.

Interesting. May I ask what do you base that on? If you're a programmer and you have looked at the code, I would be very keen to pair with you to get you started on working on this.

I would love to understand what insights you have gained to feel that it is manageable. Perhaps you have spotted some strategies that I have not.

[claremacrae]

In which case, they would become due ranges, not due dates.

Which is kind of what start dates and due dates are, really.

[Kongolan]

I am missing something fairly fundamental. Which aspect of Tasks are you thinking this would appear in?

Are you thinking it would apply to the date values in individual tasks (like due dates)? In which case, they would become due ranges, not due dates.

Yes, exactly that. I think you should be able to write something like "2023-W04" into due, scheduled or start dates instead of "2023-01-25". They are now ranges, or more like I want to set it to this week.

Or are you thinking it would apply to queries?

And yes, they should show in queries then. As the last day of the week or month obviously. The queries need to be expaned to fit this.

This should be a huge but managable overhaul in my opinion.

Interesting. May I ask what do you base that on? If you're a programmer and you have looked at the code, I would be very keen to pair with you to get you started on working on this.

I would love to understand what insights you have gained to feel that it is manageable. Perhaps you have spotted some strategies that I have not.

I think your concern is correct. It won't be that easily done. I once contributed to this plugin already, when I did the pull request on the "happens" query back then.

As far as I remember, those new due, start, scheduled, happens ranges need to be added to the algo, which handles the dates itself. Hopefully implementing something smart in the core of the plugin, can make this work out of the box. We just need a way to resolve those new date input like "2023-M02" or "2023-W07".

[Kongolan]

I need this addition to adapt this GTD system here on Todoist, what I want to replicate in Obsidian. It's a very simple system, which is pretty effortless. The task plugin should be able to help me replicate the Todoist filters simply like that. Only the moving the tasks between folders like next or this week, is something, which is hard to replicate.

I think others have suggested alternative ideas like making it easy to bump tasks over from one day or week to the next.

So you are correct to assume, that it's about moving tasks effortless in time. I just thought that adding something like W04 is faster written, then moving the task to another date like from 2023-01-25 to 2023-01-28, to realize that the task won't be done on the 28th neither and I need to move it again.

Here is the video: My Todoist Set-Up (Early 2022) - YouTube

[claremacrae]

Oh wow, thanks for happens - I use it a lot.

Over time I have been refactoring the core of this plugin, to make it easier to modify. Kind of like the adage "make the change easy, then make the easy change".

I started refactoring all the date storage to introduce TaskDate class - but got diverted along the way: https://github.com/obsidian-tasks-group/obsidian-tasks/tree/refactor-add-TaskDate-class

I think if I started this again I would be able to make the change more efficiently.

Also, since you contributed happens, I've refactored the filter classes a lot to remove duplication.

A nice spin of from this could be filters that match the same syntax - for example due in 2023-W04. This would be a very popular feature, and weeks and quarters are not well represented in the underlying library.

[TomWol]

I have been designing a personal tasks system in Obsidian and have been struggling to find a good way to implement this aswell within the functionality of this excellent plugin.

In my case I am trying to implement a Bullet Journal approach. Specifically for this part, the idea is to aid in organizing your tasks by first scheduling them in a particular month or week. Then with a clear overview of your calendar and your tasks for that month or week, you can schedule tasks more specifically on days with free time.

For the monthly approach, I thought about doing it by setting Start Date as the first day of the month and Due Date as the last of the month (as @claremacrae mentions, the range between start and due implies the task is 'monthly'). However I find this kind of blurs the distinction between scheduled, start and due date, I'm mixing them up quite a bit for what is my intended goal of 'scheduling'. The goal is not necessarily that tasks are due this month, I am merely trying to schedule them, it's fine if I don't get to finish them all.

It also overcomplicates other queries a lot, for example finding all tasks that have specific due dates in the future, querying tasks that are due today (when today is the last day of the month) or starting today (first day of the month). Add in Dataview Template literals (which most of my Tasks blocks use) and I just seem to get further away from the beautiful simplicity of the Tasks query language.

I think 2023-M02 and 2023-W04 are clear syntax-wise. I dare dream of even planning tasks in particular weeks of months, but I can't think of a good syntax without ambiguity so I'd just be happy with the first two. The due in 2023-W04 seems like an excellent filter aswell.

It's important to think about how these ranges would work when you query the data in the context of:

• Grouping: do you show the task for every date in the range or is the range a separate group? I'd say the latter?
• Sorting: how is urgency re-calculated?
• Natural languages: in two weeks - is that a date or a range?

I'm really excited about the possiblities though. If I were any good at programming, I would help out...

By the way, thank you @claremacrae for all your work on this plugin and particularly the recent update supporting custom statuses. This makes the Bullet Journal approach via Tasks much more feasible.

[ilandikov]

For my task management I'm was trying to switch to kanban approach, but with lists of tasks instead of cards. I was hoping to use Canvas + Tasks, but switched to Canvas + Dataview (DQL TASKS). However it doesn't look as good as Tasks plugin because there is not much configurability of the task output in DQL TASKS.

So a feature where I can isolate tasks due/scheduled/happening/done in a particular week or month would be useful for me - I could create a kanban for each time period. Maybe it could be worth to extend it to quarter 2023-Q[1-4], semester 2023-H[1-2], year 2023.

On a side note, I would vote to use 2023-01 (instead of 2023-M01) for the month selection as we naturally use YYYY-MM-DD format in Obsidian so truncating that to YYYY-MM should be more intuitive for most of the users.

Another idea could be keeping due/scheduled/happens/done in ... for the exact time periods as it is now and creating a due 2023-W03 styled filters without the in keyword. Just thinking out loud ˆˆ

Many thanks to @TomWol and @Kongolan for the ideas.

[claremacrae]

I feel like I don’t understand what the actions for this feature request are.

Can anyone see a way to break this request down into separate specific actions please?

there is already #1613 for filtering on ranges of dates. That is the sort of clarity and granularity of request that has a high chance of being doable.

What are the other specific actions - for filtering and for data values on individual tasks - that re required for this request to be considered to be done.

thanks in advance.

[ilandikov]

I could see the following architecture for this:

Date filters such as happens, due, etc accept now the following structure: <dateFilter> (before|after|on) <date>

I suggest accepting also <dateFilter> (no keyword or "in" - up to you) <dateRange> where dateRange can be:

• YYYY for a year
• YYYY-H[1, 2] for half a year
• YYYY-Q[1-4] for a quarter
• YYYY-[01-12] for a month
• YYYY-W[01-52/53] for a week (some years have 53 weeks)

So if we agree on this solution the actions from my viewpoint are:

• enable type
• accept date range expession in a query with no keyword or "in" keyword (or else)
• convert the date range expression to type
• filter the tasks according to the

[claremacrae]

Thanks @ilandikov - it is rather more work than that. See https://github.com/obsidian-tasks-group/obsidian-tasks/issues/1582#issuecomment-1402869843 - and I am unsure that all the later comments are referring to the same functionality.

At least one refers to moving tasks effortless in time which is a whole different topic again.

[ilandikov]

@claremacrae oh, you are right, I just read again the comment you mentioned. So we are talking about 2 different things then:

• queries with data ranges as described in my last comment. Shall I submit another issue for that? Do you agree with the proposed structure? The whole thing should take place in DateField.createFilterOrErrorMessage(): the new keyword with a check whether the Task's date in the filter range
• input with data ranges (the original topic requested by @Kongolan)

for the second point, I checked the code and I have the following conclusions in mind, need your check here: general

• allow "date scopes" only for due & scheduled (below I will mention due only for shorter description but mean both)
• dueDate in Task class shall accept [Moment, Moment] tuple type task parsing
• TaskRegularExpressions shall have dueDateRange[W, M, Q, Y]Regex and dueDateRange[W, M, Q, Y]Format
• In Task.fromLine(...) there should be a matcher of dueDateRange[W, M, Q, Y]Regex which will in case of match create the dueDate field with [rangeStart, rangeEnd] task quering
• I opened DueDateField and realised this is going to be more difficult than I thought =) but I will continue the description for the sake of the experiment =)
• Add a keyword to the dueRegexp, indeed we need a keyword in `(before | after | on)' group to distinguish the range
• DateField.createFilterOrErrorMessage() shall have a separate parsing path if the Task's date is a range, check if the filter's date is in that range. I guess this is the most difficult and cumbersome part. Probably the whole thing would be easier if another field like dueDateRange with Moment type is added to the Task class, where we set the range if any. But this would add a lot of if (dueDateRage) {...} instead of different type management
• Also there should be treatment of the task modification modal, I didn't dive there...

This is a lot of work indeed and I see what you mean now =) Please let me know if you see a viable path somewhere.

[claremacrae]

@ilandikov Sorry, I was unclear that what I was asking for is only a description of the user-visible behaviour.

It would be better not to talk about places in the code, at this stage, but to focus purely on the desired behaviour. It could be weeks or months until this is implemented, and the code structure could be completely different by then.

[claremacrae]

Please let me know if you see a viable path somewhere.

What I have found is that when feature requests start off as too widely scoped, they tend to rapidly accumulate more long comments that are also widely scoped, and it becomes ever more time-consuming to parse them, and tease out what all the requested actions are, in between the background.

My initial instinct with this one was that it was already widely scoped, because it covered both data in the tasks and the filtering system. But I hesitated and didn't close it, as it's never nice closing an issue...

However, the fact that @ilandikov didn't spot the fact that it was also a data request is a good indication of that this has grown.

I do appreciate the time that people have taken to add comments here. But I also have to be realistic about the time available to develop and support the plugin.

So I am sorry but in the interests of using developer time effectively I am going to close this as too wide a scope to be able to be done in a feasible amount of time, both for the amount of work required, and the amount of time required to pull out detail from the comments.

If anyone who has added comments here feels that they would like to make specific feature requests for small bodies of work, I would appreciate that very much.

On the other hand, I would totally understand if anyone was unsure about what was small enough. If you have a particular scenario that you are struggling with, the best thing to do is to describe it in a Q&A discussion, and we can see what is currently possible, and take it from there....

[claremacrae]

I need this addition to adapt this GTD system here on Todoist, what I want to replicate in Obsidian. It's a very simple system, which is pretty effortless. The task plugin should be able to help me replicate the Todoist filters simply like that. Only the moving the tasks between folders like next or this week, is something, which is hard to replicate.

I think others have suggested alternative ideas like making it easy to bump tasks over from one day or week to the next.

So you are correct to assume, that it's about moving tasks effortless in time. I just thought that adding something like W04 is faster written, then moving the task to another date like from 2023-01-25 to 2023-01-28, to realize that the task won't be done on the 28th neither and I need to move it again.

Here is the video: My Todoist Set-Up (Early 2022) - YouTube

@Kongolan Sorry but I do not have time to watch a video ...

The task plugin should be able to help me replicate the Todoist filters simply like that

nor to learn about another system simply to help someone else replace it.

[claremacrae]

I have been designing a personal tasks system in Obsidian and have been struggling to find a good way to implement this aswell within the functionality of this excellent plugin.

In my case I am trying to implement a Bullet Journal approach. Specifically for this part, the idea is to aid in organizing your tasks by first scheduling them in a particular month or week. Then with a clear overview of your calendar and your tasks for that month or week, you can schedule tasks more specifically on days with free time.

@TomWol Please raise this in a Discussion Q&A...

[claremacrae]

Hi @ilandikov Huge thanks for your help on this issue.

If you had time to create an feature request to cover the request for date ranges on tasks themselves, that would really help. But I would have it support all of Scheduled, Due and Starts... Then people could (eventually) search it will Happens...

[ilandikov]

It would be better not to talk about places in the code, at this stage, but to focus purely on the desired behaviour. It could be weeks or months until this is implemented, and the code structure could be completely different by then.

That's quite a good point, I take note for future. And thanks a lot for sharing the realistic approach.

[claremacrae]

Hi @ilandikov Huge thanks for your help on this issue.

If you had time to create an feature request to cover the request for date ranges on tasks themselves, that would really help.

Don't worry, I will do this now...

[Kongolan]

Thanks @ilandikov - it is rather more work than that. See #1582 (comment) - and I am unsure that all the later comments are referring to the same functionality.

At least one refers to moving tasks effortless in time which is a whole different topic again.

No, don't worry about me. My idea wasn't fully fletched out. I go along with what @ilandikov suggested. His approach seems fine to me.

Moving tasks effortlessly is cool, but I was mainly looking to schedule them by week.

[claremacrae]

On reflection, I think the design of this plugin for scheduling to work on a task over a date range, like a week, was to use start and due dates.

[ilandikov]

On reflection, I think the design of this plugin for scheduling to work on a task over a date range, like a week, was to use start and due dates.

Don’t you think that the start date is the start of doing the task eg the task is in progress at that time? I’m just thinking out loud, dunno the best solution here

[aubreyz]

Don’t you think that the start date is the start of doing the task eg the task is in progress at that time? I’m just thinking out loud, dunno the best solution here

I have always imagined the start date/threshold date (in all todo systems I have used) as the date before which I don't want to see the task at all for any reason (including possibly seeing it only to reschedule it or to delay that start date). I don't think it is useful to have a concept of recording when a task was in some sense actually "started" (I'm not sure what that even means)

[claremacrae]

Yes, different people use the 3 dates for different meanings and that is fine.

[ilandikov]

@aubreyz @claremacrae thanks for your comments, indeed the focus shall be on the functionality and the user shall use it up to their choice