--- /dev/null
+Return-Path: <sojka@os.inf.tu-dresden.de>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 22DD3429E25\r
+ for <notmuch@notmuchmail.org>; Mon, 15 Aug 2011 02:30:40 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+ autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id BgKsHNdno4Gy for <notmuch@notmuchmail.org>;\r
+ Mon, 15 Aug 2011 02:30:38 -0700 (PDT)\r
+Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36])\r
+ by olra.theworths.org (Postfix) with ESMTP id 518C3431FB6\r
+ for <notmuch@notmuchmail.org>; Mon, 15 Aug 2011 02:30:38 -0700 (PDT)\r
+Received: from localhost (unknown [192.168.200.4])\r
+ by max.feld.cvut.cz (Postfix) with ESMTP id B976D19F3332;\r
+ Mon, 15 Aug 2011 11:30:37 +0200 (CEST)\r
+X-Virus-Scanned: IMAP AMAVIS\r
+Received: from max.feld.cvut.cz ([192.168.200.1])\r
+ by localhost (styx.feld.cvut.cz [192.168.200.4]) (amavisd-new,\r
+ port 10044)\r
+ with ESMTP id 0-UA34-0UH4P; Mon, 15 Aug 2011 11:30:36 +0200 (CEST)\r
+Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34])\r
+ by max.feld.cvut.cz (Postfix) with ESMTP id 6497719F32DB;\r
+ Mon, 15 Aug 2011 11:30:36 +0200 (CEST)\r
+Received: from steelpick.2x.cz (unknown [141.76.49.12])\r
+ (Authenticated sender: sojkam1)\r
+ by imap.feld.cvut.cz (Postfix) with ESMTPSA id 35807FA003;\r
+ Mon, 15 Aug 2011 11:30:36 +0200 (CEST)\r
+Received: from wsh by steelpick.2x.cz with local (Exim 4.76)\r
+ (envelope-from <sojka@os.inf.tu-dresden.de>)\r
+ id 1QstVE-0002B0-1k; Mon, 15 Aug 2011 11:30:36 +0200\r
+From: Michal Sojka <sojkam1@fel.cvut.cz>\r
+To: Jani Nikula <jani@nikula.org>, notmuch@notmuchmail.org\r
+Subject: Re: [RFC PATCH 3/3] lib: add gnulib get_date() based date range\r
+ search\r
+In-Reply-To:\r
+ <8ed532337c898d9075bbce00a7b2aaf9f13283b0.1312964528.git.jani@nikula.org>\r
+References: <cover.1312964528.git.jani@nikula.org>\r
+ <8ed532337c898d9075bbce00a7b2aaf9f13283b0.1312964528.git.jani@nikula.org>\r
+User-Agent: Notmuch/0.6.1-91-g55c2c34 (http://notmuchmail.org) Emacs/23.3.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Mon, 15 Aug 2011 11:30:36 +0200\r
+Message-ID: <87aabbyqbn.fsf@steelpick.2x.cz>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Cc: amdragon@mit.edu\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Mon, 15 Aug 2011 09:30:40 -0000\r
+\r
+On Wed, 10 Aug 2011, Jani Nikula wrote:\r
+> Add a custom value range processor to handle "date:" using get_date() from\r
+> gnulib. This enables date (and time) searches of the form\r
+> date:since..until, where "since" and "until" are expressions understood by\r
+> get_date(), compatible with most GNU programs. For the date input formats,\r
+> see the GNU coreutils manual:\r
+> http://www.gnu.org/software/coreutils/manual/html_node/Date-input-formats.html\r
+> \r
+> Open-ended ranges are supported (since Xapian 1.2.1), i.e. you can specify\r
+> date:..until or date:since.. to not limit the start or end date,\r
+> respectively.\r
+> \r
+> Note: The get_date() function has been renamed to parse_datetime() in\r
+> recent gnulib.\r
+> \r
+> EXAMPLES:\r
+> \r
+> date:2-weeks-ago..\r
+> date:today00:00:00..\r
+> date:yesterday00:00:00..today00:00:00\r
+> date:07/14/2011..2011-07-15\r
+> \r
+> BUGS/CAVEATS:\r
+> \r
+> At the moment it seems search phrases with spaces in them are not supported\r
+> in notmuch. For date: this means you can't specify a date with an\r
+> expression with spaces in it. In many (but apparently not all) cases you\r
+> can work around this by replacing spaces with '-' or simply leaving out\r
+> whitespace. For example, date:2-days-ago..yesterday00:00:00.\r
+\r
+For other search operators you can quote the arguments. Doesn't that work\r
+here as well? E.g. date:"2 days ago..". \r
+\r
+> \r
+> For the purpose of searching mail, the get_date() implementation has some\r
+> surprising interpretations. For example:\r
+> \r
+> * Any date specification without time, such as date:yesterday.. or\r
+> date:2011-08-10.., means that day at the same time as now (instead of\r
+> 00:00:00).\r
+\r
+Yes, this is annoying. I think that the approach outlined in my previous\r
+mail (id:87bovryqp0.fsf@steelpick.2x.cz) would solve this nicely.\r
+\r
+> * As a consequence, ranges such as date:yesterday..yesterday match just the\r
+> messages at the same time as now, to the second. The date parser should\r
+> optimally make different kind of interpretations depending on whether\r
+> parsing "since" or "until". For example, date:today..today should cover\r
+> the whole day from beginning to end, date:today00:00:00..today23:59:59.\r
+> \r
+> * date:monday.. means date:next-monday.. (rather than date:last-monday..)\r
+> \r
+> * date:this-week.. really means date:now.. (you probably want\r
+> date:1-week-ago-next-monday00:00:00.. or similar).\r
+\r
+I looked into that in the past and found the place where it can be\r
+changed, but as you point out below, we would lose compatibility with\r
+GNU and we would need to test it. I believe that writing a new parser\r
+that is more tailored to email searching is better then reusing date\r
+parser for things it was not intended for.\r
+\r
+-Michal\r
+\r
+> \r
+> However, there is value in being compatible with GNU programs, and the\r
+> input formats have been rather well documented. It would be more surprising\r
+> to deviate from that, and it would also take some effort to do so,\r
+> including testing.\r
projects / notmuch-archives.git / commitdiff