A task shouldn't become due before it is scheduled.

[rcaputo]

Based on my understanding of scheduled and due dates:

A task becomes due at due - rc.due. At that time it begins to be included in +DUE and to be displayed with color.due.

The earliest opportunity to work on a task can be scheduled later than due - rc.due. Doing this causes tasks to appear as "due" in reports and take on "due" urgency before any work on them can be done.

While these due-before-scheduled tasks can be hidden with wait, it's my opinion that preventing the condition would be a better solution.

Suggested change:

For any given task that is both due and scheduled, consider its rc.due to be min(rc.due, due - scheduled).

If rc.due is recalculated for a task, use the recalculated rc.due when determining task color and whether to include a task in a report.

If rc.due is recalculated for a task, use the recalculated rc.due when pro-rating urgency.due.coefficient for the task. Tasks with smaller windows of opportunity should increase in urgency faster.

[djmitche]

I like this idea! I'd like to get some feedback from folks who use these two features together. It might be a surprising change, and may even cause problems for some users' situations.

[rcaputo]

Totally fair. Maybe it can be optional if the idea turns out to be divisive.

It might be fun (or at least flexible) if rc.due could be an expression evaluated within the context of a prospective task.

task's current expression parser can simulate conditionals by multiplying by relational subexpressions, but it's not pretty.

In the examples below, consider the SCHED and DUE environment variables to be task data members. (Digression: task ID calc could be handy.)

Scheduled 1 day before due:

export SCHED=2026-01-30
export DUE=2026-01-31
task calc "( $SCHED <= $DUE and $SCHED > ( $DUE - 7d ) ) * ( $DUE - $SCHED ) - ( $SCHED > $DUE or $SCHED <= ( $DUE - 7d ) ) * -7d"

P1D

Scheduled more than 7d before due:

export SCHED=2026-01-01
export DUE=2026-01-31
task calc "( $SCHED <= $DUE and $SCHED > ( $DUE - 7d ) ) * ( $DUE - $SCHED ) - ( $SCHED > $DUE or $SCHED <= ( $DUE - 7d ) ) * -7d"

P7D

Scheduled after due, in case the scheduled date of an unscheduled task evaluates to an unreachable future date.

export SCHED=9999-12-31T23:59:59
export DUE=2026-01-31
task calc "( $SCHED <= $DUE and $SCHED > ( $DUE - 7d ) ) * ( $DUE - $SCHED ) - ( $SCHED > $DUE or $SCHED <= ( $DUE - 7d ) ) * -7d"

P7D

[ryneeverett]

Is there an advantage of storing the incoherent values and calculating a more reasonable due date versus catching the incoherence at the time it arises? The "empty filter" prompt might be a good model here since in both cases the goal is to try to prevent users from doing something stupid.

[rcaputo]

Is there an advantage of storing the incoherent values and calculating a more reasonable due date versus catching the incoherence at the time it arises?

I assume you mean scheduled > due as there are valid use cases for schedled > due - rc.due.

This is probably a question for a separate issue. rc.due = (expression) can handle incoherent input. Preventing incoherence isn't a necessary prerequisite.

I'd say "no", though.

I assume the backward-compatible default would be rc.due = 7d. This would be unaffected by incoherent data. Incoherence only becomes a problem for users who opt into fancier expressions. Then those users are faced with the choice of fixing their expressions or fixing the incoherence in their data.

[KingOfSpades]

I can see this being beneficial. I use +ACTIVE +DUE as my default report. I have some recurring tasks for the weekend that are scheduled for Friday and due Sunday that appear on my default rapport now. I could use wait:due-2 but I think having it also not be included in +DUE makes more sense.

[felixschurk]

I think also the proposal seams reasonable. How much work would it be to change it?

[djmitche]

That doesn't sound too difficult. @rcaputo has already identified a few places this needs to occur -- calculating virtual tags and in urgency calculations. Happily, Taskchampion does not have a notion of "due" so nothing needs to change there.