Jump to content
Sign in to follow this  
Alice-the-Camel

(Archived) Syntax for saved search that uses relative date argument

Recommended Posts

I want to have a bunch of notes where the subject, or more likely, the tag, will involve a date allocation (e.g.02-2011).

Can I set up a saved search where the search criteria includes a date argument so that it automatically looks for notes tagged with the current date, particularly the month, in mind?

e.g. Search dialogue: tag: (month, year)

I want this saved search to be called "This Month", and have it automatically search for all notes that are tagged with the current month/year. That way, when the search is activated, I will always just get the notes for the current month/year.

I realise there are other ways of doing this, just wanted to see if the search syntax allows for this type of variable in the search.

Chris

Share this post


Link to post

It would be tough to do this if the date you're looking for is just part of the text that you've typed into some part of the note. I.e. it's feasible for the structured date fields we've used (created, modified), but hard for plain text.

If you carefully formatted your dates as something like 20101007, then you could search for notes in October 2010 by searching for: 201010*

But this wouldn't allow you to do arbitrary ranges of dates.

Share this post


Link to post

What if the saved search was looking for specific tags, not body/title text?

e.g. a bunch of tags under a "Timeline" heading, such as: 022010, 032010, 042010, 052010, ..........032011 etc.

I might be tagging photos of receipts and want to record which month they were generated, (which won't always correspond to the creation date, or modification date). Or may assign project activities to be actioned within a given month.

In comes a saved search, specifically looking for notes tagged with the current month/year (and any other relevant criteria), where I imagine the search syntax would have to have scope for a "SetCurrent(Month,Year)" type of expression in the tag search as follows:

search = tag: (SetCurrent (Month,Year))

Hence EN can automatically calculate/lookup the current date info, then initiate the tag search.

Hope this explains my point better.

Chris

Share this post


Link to post

If you carefully set up the dates in the format I described, that would work as tags by allowing you to match the first (most significant) part of the date if you put a '*' at the end. E.g.:

tag:201010*

That would match any note that was tagged with a tag that started with '201010'

Share this post


Link to post

OK.

So I guess you're saying that there isn't scope for the search expression to carry a variable such as the current date, that would be automatically updated each time the search is run. Instead it has to be a fixed value.

Chris

Share this post


Link to post

Tagging is great, but diligently tagging everything isn't always convenient, and recognizing dates in text search isn't trivial. I like building on existing tools, like, the search grammar, say:

We currently have two dates to play with (created: and updated:, and we may have a third some day (due:).

If we added into the grammar a new date format, neither absolute nor relative, but, say, fuzzy, we could do some interesting things. For the sake of avoiding ambiguity, we could wrap the new date format in curly brackets {}. Off the top of my head, here's a specification:

 -->  '{'  * '}'

--> 'created:' | 'updated:' | 'due:'

--> | | | |

--> 'year' '(' * ')'
--> | | '@'
--> '[' * ']'
--> | '-'

--> 'month' '(' * ')'
--> | | '@'
--> '[' * ']'

--> 'day' '(' * ')'
--> | | '@'
--> '[' * ']'

--> 'week' '(' * ')'
--> | | '@'
--> '[' * ']'

--> 'weekday' '(' * ')'
--> | | '@'
--> '[' * ']'

In the various , , , and productions, the '@' symbol stands for 'current, i.e. 'current year', 'current month' and so on.

Yikes, bored yet? So how does it work?

* The original poster wants to be able to find notes with a date of the current month (and let's choose the created date). The search string would then be created:{month(@)}. For notes with a date of June, any year, we'd have created:{month(6)}, For notes in the months of March through June, any year: created:{month([3-6])}. And so on.

* I want to find all of the notes created in 2007: created:{year(2007)}. For notes created in the years 2005, 2006 and 2007: either created:{year(2005, 2006, 2007)} or created:{year(2005-2007)}.

* For a note that I always want to update every Friday: due:{weekday(5)}.

And so on.

We could maybe allow some math: created:{year([(@-2)-@])} would be notes created in the last three years. How about allowing month and weekday names? For example: created:{month(June,July,September-November])}.

Sorry if this is overlong, or inappropriate for the forums. This kind of thing is interesting to me. I also haven't given any consideration as to how the search engine would actually implement the searches for these beasts. But something to chew on, if you Evernote folks get bored or find yourselves at a loss for something to do (hah).

~Jeff

Share this post


Link to post

Oooh, pseudo-BNF!

Thanks for the suggestions. This is one of those cases where the cross-platform nature of Evernote make it tricky to tweak/change the search grammar, since people expect the same search (especially the saved searches) to produce the same results everywhere. This translates into changes on the Mac (in Obj-C/Cocoa), Windows (in C++ for v4), and web service, and also comparable work on the mobile platforms with offline searching support.

If I could just throw these changes into the server-side implementation, that would make it a small project, but the cross-platform nature of our service has prevented us from making a lot of changes to the search syntax and core data model.

Share this post


Link to post
I might be tagging photos of receipts and want to record which month they were generated, (which won't always correspond to the creation date, or modification date).

If it were me, I'd simply change the creation date of the receipt note to the date of the receipt. But if you didn't want to do that, the next suggestion would be to title all receipts either "20101005 - Applebee's" or "Applebee's 20101005". Personally, I prefer the first method b/c it will arrange all receipts by date, if you sort on the title. (And if you have them all tagged as receipts or in a receipts notebook.) Plus, it looks a lot more tidy since the first 8 characters are the date & the vendor name always starts in the same position. Not that I'm anal about these things. :(

This way you could also find the receipts for a particular month (or date) by searching:

intitle:"201010"

intitle:"20101005"

But this still doesn't do a range, say Sept 29 - Oct 5. BUT...if you changed the creation date to the receipt date, you'd be better able to do the date range by using the created since last week, last month. But it's still not a specific date range.

Oooh, pseudo-BNF!

:lol:

Share this post


Link to post
Oooh, pseudo-BNF!

Yeah. I'm a geek, it's true. I've done some parsing/compiling work in my past, and it's always been on the higher end of the 'interesting' scale, so it was a bit of a fun exercise while winding down for the night. 'Psuedo-' is about right -- it's not particularly formal. Good thing you didn't see my first idea -- it was less than 'pseudo-' and more like 'half-baked'.

Thanks for the suggestions. This is one of those cases where the cross-platform nature of Evernote make it tricky to tweak/change the search grammar, since people expect the same search (especially the saved searches) to produce the same results everywhere. This translates into changes on the Mac (in Obj-C/Cocoa), Windows (in C++ for v4), and web service, and also comparable work on the mobile platforms with offline searching support.

If I could just throw these changes into the server-side implementation, that would make it a small project, but the cross-platform nature of our service has prevented us from making a lot of changes to the search syntax and core data model.

Obviously I know about your cross-platform compatibility challenges, it's just lately I've been thinking about long-term storage of lots of notes, and how to handle them effectively. One way would be to make better search tools -- or ones that take better advantage of existing data/attributes -- and I figure you'll be doing that eventually on your own anyhow. I mean, you're going to be around for a few years, right? :(

~Jeff

Share this post


Link to post

We're planning to add a "due date" attribute to the notes, with a UI to set it. You could use this field for your own purposes if you don't want to use it for To Do scheduling.

Share this post


Link to post
Guest
This topic is now closed to further replies.
Sign in to follow this  

×
×
  • Create New...