Date search operator suggestions

I found in a post that the following search is supposed to show things before the end of the week.

@due <[d] end of next week

But it does not work in version 163 running OS X 10.11.2

My suggestion would be to add some sort of search options so that one can specify how many days you want when filtering. Maybe something like,

@due <[d]+12

to search things that are due in less than twelve days. This can be pushed even further by using another letter for months [m] and years [y] (I have no clue from where comes the “[d]” standard.) With this implementation, one could search for all the task due in two months like this,

@due <[m]+2

1 Like

I’m not sure where that post was, but it must have been a syntax suggestion or possibility… so far I haven’t implemented anything like that. The only date search keywords that I’ve implemented are today and tomorrow. Longer term I do hope to add to this, but so far date search only knows about those keywords.

That’s an interesting approach that I hadn’t considered or seen used in many natural language date parsers. I’m still thinking about date syntax. I want to hold off a bit longer before I start down a direction that I later decide that I don’t like.

In the meantime… are there a few “must have” date queries that people need? Eventually I’d like date queries that can target most any date easily, but may I can get by with a few more hard coded cases right now?

What queries do people want to be making?

There was several references to “end of next week” in the topic where people were talking about saving searches Saved Searches in TP3.

I think that if you are talking about “hard coded cases,” my needs would be something like:

one week
two weeks
one month
one year

I do think that the “end of” part of “end of next week” is really unnecessary since it is assumed that we are talking about the next seven days. Even the “next” would be over-complicating things since that type of language is very precise (sometimes it reads awkwardly with the < > operators.) Again, I do not know if you were planning to implement that, but since you included that in your save search example, I am just adding my two cents :smile:

If you want to follow the natural language approach, adding a "day(s)"option(s) to what I already mentioned would work. Of course, now you would be dealing with parsing how many “days|months|years” we want to look into.

That is why from a programming and logical sense, [d] | [w] | [m] | [y] + # is kind of natural. I mean, it took me a while to figure out that to request the day, I had to do “[d] today.” Now that I know, it makes sense; but before, I was breaking my head – and I do not consider myself mentally inflexible and I read quite a bit of the documentation available. Nobody comes up with “[d] today” in a “intuitive and natural” way just out of the blue. In the same way, I think that just including a quick line in the manual mentioning that the parameters are “[d] + #ofDays” would be as intuitive as the other option.

I had thought that [d] was just tripping the date-operations parser, not meaning “day” but “date”. Given that, I didn’t find @due <[d] today+5 to be unintuitive (and had actually tried that out, but failed to find it working, of course). It does seem to me that the end of you mention, @Victor, is probably necessary: some users might assume that a search like @due <[d] next week means "due before (the beginning of) next week. As a linguist anyway that’s my two cents.

Another way that it might be interesting to hard-code some of this minimally is using this week|month|year, picking out the relevant specific dates - and then to play with the addition possibilities on top of that.

Unless you really go all out on the natural language support it will get confusing to have more than two. Once the outcome is unpredictable I don’t think people will trust it. Once “next Wednesday” fails I think it would be confusing. I’d prefer the suggested [d] +5d to indicate 5 days in the future.

For me it also more closely resembles what I use on Windows with the PlainTasks package for entering due dates as @due(+5d) (tab triggers conversion of +5d to 5 days in the future as YYYY-MM-DD) which I’d also love to see in TP3.


I have to agree with @macdrifter, in that I’d love to see some cues taken from PlainTasks when dealing with dates. Granted it may not be easy to pull off, but I’m confident it’ll pay off in the long run. That’ll avoid the need for complex TextExpander snippets that many users won’t even know how to achieve.

I think I actually prefer the +5d, +12h, +1y type of syntax. Seems more explicit.

1 Like

As I was typing a reply, it dawned on me that there are 2 distinct things that need tackling and I was focused on just one.

Inputting dates and searches.

For inputting dates, I absolutely love PlainTasks implementation of triggering a hardcoded date when doing @due( +5d).

For searching being able to do @due > tomorrow +5d would be stellar indeed. The two in conjunction would make plenty of sense since the syntax is identical and therefore would make it rather easy to grok, even for novice users. +5d, +12h, +1w would mean the same thing whether inputing a date or whether searching dates.

1 Like

I think I’d prefer search/filter syntax like Needs Review @search(@review < [d] +14d except @done) where it’s always relative to today. Maybe just me.

Yep, that’s what I was driving at too, however when inputing dates in a task, having a hardcoded type expand when typing +5d makes more sense than having a due date of @due(+5d) since that gives you no context. Search however I totally agree with you that it should be relative to today (I see I typed tomorrow when I meant today… :grin: )

That is exactly (what pslobo and macdrifter showed) what I wrote in my original suggestion. The improvement of adding the d | w | h | m | y to the number of date units really makes sense and improves upon the original idea.

Although it doesn’t follow the “natural language” format, we have to admit that sometimes the “natural language” ends up being more confusing because it demands more clarity or verbosity. For example, “week.” What do you mean with week? seven days? the beginning the week? When does the week begin (Sunday, Monday)? etc.

One would just have to assume that “[d]” stands not only for “date” but also “today,” but honestly, that is not that difficult to comprehend. Maybe for the sake of clarity, the term “today” could be kept. So that the search macdrifter had,

Needs Review @search(@review < [d] +14d except @done)

Could be done like the following,

Needs Review @search(@review < [d] today +14d except @done)

But whether it is decided to keep “today” or not, adding these operators to the filtering of TaskPaper would made this application incredibly more useful.

Would having a “Before” and “After” syntax help? I’m thinking the following:

before 1w
after 2d
after 1w before 4w
after 2015 before 2017
after 2015-12 before 2016-02

If you had h=hour d=day w=week m=month y=year

This would seem to give you the ability to be as flexible as you need to with little effort.

I just read in your documentation that you are using moment.js to parse dates. Since you are already using moment.js, would not be easier to use the operators that library uses to add and subtract dates when searching for dates? This is what I mean.

Since you can do something like this in moment.js

Date.subtract({years: 2, days:1});

Could it be possible to use this to do something like this in TaskPaper using that library?

@due>[d] now.subtract(‘days’,14)
@due>[d] now.add({years: 2, days:1})

Sorry Victor, but for me that would be completely unintuitive as a non-coder. It looks too complex.

I think I won’t do that… the parsing of whatever syntax is decided upon isn’t that hard in the end. It’s just coming up with a good syntax. (actually parsing and executing that moment code in a safe way would be a lot harder!). But this suggestion still helps me out… I’ve started a few small attacks at this problem and have been using JavaScript date operators to put everything together… forgot I had moment around. Will shorten up my code a bit to use the moment APIs instead to turn my parsed values into a Date. Thanks!

Finally got this in place. Date/time syntax is documented in user’s guide:



I’m still having a little bit of trouble understanding the syntax. Based on the documentation, it looks like the query

@due <=[d] +1 week

run today, Feb 2, should show the task

  • wash the car @due(2016-02-04)

What am I missing? Thanks!

Seems to be working here …

1 Like