Comparison between list of dates and date always returns true

What happened?

toy case

• A [due:: 2023-01-16T09]
• B [due:: 2023-01-06]

Lorem ipsum dolor sit amet.

• C
• D

faulty TASK dataview

The following dataview will show C and D, although they

• have no due date
• no due date in the whole note is actually in the past (as checked for in the WHERE)

TASK 
WHERE due < date(now)

faulty TABLE dataview

TABLE T.text, T.due
FLATTEN file.tasks AS T
WHERE T.due < date(now)

This also yields both C and D, with empty due dates as reported by the column…?

DQL

No response

JS

No response

Dataview Version

0.5.47

Obsidian Version

1.0.3

OS

MacOS

[s-blu]

thanks for the support re avoiding. I just accepted now that I can’t idle tasks by removing the [ ] because dataview then interprets the idled-task-properties as file properties.

You could do so by i.e. adding another property or a tag #idle to them and exclude them in your query via FROM -#idle. Just as an idea.

To my mind, blocking “defer” and “due” from ever inheriting file properties would feel right. these feel like exclusive members of tasks, their parents, their children. But I am sure there are other users that desire this file inheritance. There always are. So from my point of view, this can be closed if no change re fallback behavior is desired.

As somebody that uses due dates on file, I can only agree that the desired behaviour here is very depending on the workflow 😃

I’ll wait for blacksmithgus answer and close the issue if no adjustment of the fallback comparison is wished for. Thanks for your feedback!

[PaulAmosKreiner]

Could also say that it’s my bad then because I didn’t realize that the undefined and counterintuitive behavior does not occur in the TABLE-query that I only included for good measure… 😉

thanks for the support re avoiding. I just accepted now that I can’t idle tasks by removing the [ ] because dataview then interprets the idled-task-properties as file properties.

To my mind, blocking “defer” and “due” from ever inheriting file properties would feel right. these feel like exclusive members of tasks, their parents, their children. But I am sure there are other users that desire this file inheritance. There always are. So from my point of view, this can be closed if no change re fallback behavior is desired.