Re: [RFC PATCH 3/3] lib: add gnulib get_date() based date range search

Subject: Re: [RFC PATCH 3/3] lib: add gnulib get_date() based date range search

Date: Mon, 15 Aug 2011 11:30:36 +0200

To: Jani Nikula, notmuch@notmuchmail.org

Cc: amdragon@mit.edu

From: Michal Sojka


On Wed, 10 Aug 2011, Jani Nikula wrote:
> Add a custom value range processor to handle "date:" using get_date() from
> gnulib. This enables date (and time) searches of the form
> date:since..until, where "since" and "until" are expressions understood by
> get_date(), compatible with most GNU programs. For the date input formats,
> see the GNU coreutils manual:
> http://www.gnu.org/software/coreutils/manual/html_node/Date-input-formats.html
> 
> Open-ended ranges are supported (since Xapian 1.2.1), i.e. you can specify
> date:..until or date:since.. to not limit the start or end date,
> respectively.
> 
> Note: The get_date() function has been renamed to parse_datetime() in
> recent gnulib.
> 
> EXAMPLES:
> 
> date:2-weeks-ago..
> date:today00:00:00..
> date:yesterday00:00:00..today00:00:00
> date:07/14/2011..2011-07-15
> 
> BUGS/CAVEATS:
> 
> At the moment it seems search phrases with spaces in them are not supported
> in notmuch. For date: this means you can't specify a date with an
> expression with spaces in it. In many (but apparently not all) cases you
> can work around this by replacing spaces with '-' or simply leaving out
> whitespace. For example, date:2-days-ago..yesterday00:00:00.

For other search operators you can quote the arguments. Doesn't that work
here as well? E.g. date:"2 days ago..". 

> 
> For the purpose of searching mail, the get_date() implementation has some
> surprising interpretations. For example:
> 
> * Any date specification without time, such as date:yesterday.. or
>   date:2011-08-10.., means that day at the same time as now (instead of
>   00:00:00).

Yes, this is annoying. I think that the approach outlined in my previous
mail (id:87bovryqp0.fsf@steelpick.2x.cz) would solve this nicely.

> * As a consequence, ranges such as date:yesterday..yesterday match just the
>   messages at the same time as now, to the second. The date parser should
>   optimally make different kind of interpretations depending on whether
>   parsing "since" or "until". For example, date:today..today should cover
>   the whole day from beginning to end, date:today00:00:00..today23:59:59.
> 
> * date:monday.. means date:next-monday.. (rather than date:last-monday..)
> 
> * date:this-week.. really means date:now.. (you probably want
>   date:1-week-ago-next-monday00:00:00.. or similar).

I looked into that in the past and found the place where it can be
changed, but as you point out below, we would lose compatibility with
GNU and we would need to test it. I believe that writing a new parser
that is more tailored to email searching is better then reusing date
parser for things it was not intended for.

-Michal

> 
> However, there is value in being compatible with GNU programs, and the
> input formats have been rather well documented. It would be more surprising
> to deviate from that, and it would also take some effort to do so,
> including testing.

Thread: