Schould ACTIVE tag be applied to tasks that have their start date in the future

[KingOfSpades]

Hey!

I love Taskwarrior.

Currently I use a combination of start date in the future + a wait (example: task modify TASK start:eod wait:start) to "schedule" a task in the future. This is because when I set a start date in the future for a task it gets the ACTIVE tag and i use the ACTIVE tag as part of my "working on now" report:

$ task 41 modify start:eow
Modifying task 41 '***************'.
Modified 1 task.
Project '********' is 81% complete (7 of 37 tasks remaining).

$ task 41

Name          Value
...
Start         2026-03-29 23:59:59
...
Virtual tags  ACTIVE ANNOTATED PENDING PROJECT READY TAGGED UNBLOCKED
...

My question is, should we apply the ACTIVE tag to tasks that have start dates in the future? I can work around this by modifying my report or using a hook but I'm wondering if removing ACTIVE might be a better solution.

[djmitche]

A task is considered ACTIVE if it has been started and not stopped. It's typically set by task start which sets start to the current time. So it makes sense that these tasks have the ACTIVE virtual tag.

You may want to consider using the next tag for this "working on now" report. Something like task modify +next wait:eod will make the task next (so it has high urgency) for tomorrow (eod).

[KingOfSpades]

I use this as my default and "working on or should be working on" query: report.now.filter=(+ACTIVE or +DUE or +OVERDUE) +READY the thing I'm trying to solve is to make tasks planed in the future to appear on this report automatically. I do this by setting the start date in the future and setting a wait to hide them but it feels like I'm going about it the wrong way. Am I?

I could use report.now.filter=(start.before:tomorrow or +DUE or +OVERDUE) +READY but I prefer to go with a pure tag based approach.

I do understand having the +ACTIVE tag being set even if the start_date is in the future but I do find it odd (personal opinion).

[djmitche]

I think +next and wait:.. is the recommended way to accomplish what you're looking for.

In general, we have to pick a consistent way to handle incoherent task states such as a start date in the future, and there typically arguments for a variety of interpretations. But once one of those interpretations is implemented, users come to rely on it (hyrum's law) so changing the interpretation breaks working setups. I think this is such a case.

[KingOfSpades]

Agreed. My workflow works for me and I follow the logic of if start_date and status = pending = active. Lets not break others workflow with that. I couldn't find any other issues/discussions surrounding this but now we have some mention of it.