I am trying to create an agent that shows me notes from previous years but with the same month/day as today. I created a new date attribute $EntryDate and put the appropriate date in there.
So far, the query appears to be pulling in notes with dates of today, plus or minus one day. E.g., it is bringing in notes from June 13 (today), but also June 12 and June 14.
I know this has been an issue with people creating to-do tasks with due dates and so forth, but I thought the Date.day operator would not be looking at times, but literally just the numerical day of the month.
The change is adding parentheses around all the dot operators. I’m not sure if all are needed, but the above working whereas the the original doesn’t points to some sort of parsing confusion.
Splitting the terms out, query $EntryDate.month==$EntryDate(agent).month finds 6 items and $EntryDate.day==$EntryDate(agent).day finds 1 item. Both are correct. So I tried this:
… i.e. parentheses just around each query expression. This works and is consistent with documentation. Thus, in paragraph 5 of the latter:
If it is desired control the order in which different parts of a multi-term query are evaluated, each query term—or sub-groups of query—can be enclosed in parentheses, i.e. round brackets ‘(’ and ‘)’. As with parentheses in a spreadsheet formula, Tinderbox will evaluate the inner-most (most deeply nested) parentheses before working outwards until the whole query is evaluated.
Please don’t read this tear-down as snark. I actually did all the above steps and more (e.g. storing the .day and .month outputs in Number attributes) before validating that parentheses were needed—i.e. I had to go re-learn this myself. I figured writing some explanation rather than just posting the final solution would help the forum as a whole as there’s a useful point about parentheses in queries.
The fact that Tinderbox normally ‘guesses’ query intent correctly means that deliberate parentheses are rarely needed for simple queries, so easily overlooked. Still, this shows their value both as a diagnostic (my first query example above) and as explicit parsing markers.
