From fe71cbdfdbb1649e74264b7b4ac428cf30a02654 Mon Sep 17 00:00:00 2001 From: Michal Sojka Date: Wed, 3 Oct 2012 21:02:01 +0200 Subject: [PATCH] Re: [PATCH v3 2/9] parse-time-string: add a date/time parser to notmuch --- af/30ed90b7032e957e2343473200a96f39205e0f | 141 ++++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 af/30ed90b7032e957e2343473200a96f39205e0f diff --git a/af/30ed90b7032e957e2343473200a96f39205e0f b/af/30ed90b7032e957e2343473200a96f39205e0f new file mode 100644 index 000000000..a0435d23a --- /dev/null +++ b/af/30ed90b7032e957e2343473200a96f39205e0f @@ -0,0 +1,141 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 8FD7C431FAF + for ; Wed, 3 Oct 2012 12:02:12 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -2.3 +X-Spam-Level: +X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id QCN6Ngp9vv32 for ; + Wed, 3 Oct 2012 12:02:11 -0700 (PDT) +Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36]) + by olra.theworths.org (Postfix) with ESMTP id 750E0431FAE + for ; Wed, 3 Oct 2012 12:02:11 -0700 (PDT) +Received: from localhost (unknown [192.168.200.4]) + by max.feld.cvut.cz (Postfix) with ESMTP id 6C8573CFE72; + Wed, 3 Oct 2012 21:02:09 +0200 (CEST) +X-Virus-Scanned: IMAP AMAVIS +Received: from max.feld.cvut.cz ([192.168.200.1]) + by localhost (styx.feld.cvut.cz [192.168.200.4]) (amavisd-new, + port 10044) + with ESMTP id S15GLUU0j2GK; Wed, 3 Oct 2012 21:02:04 +0200 (CEST) +Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34]) + by max.feld.cvut.cz (Postfix) with ESMTP id ADCF419F2F35; + Wed, 3 Oct 2012 21:02:03 +0200 (CEST) +Received: from steelpick.2x.cz (rtime.felk.cvut.cz [147.32.86.92]) + (Authenticated sender: sojkam1) + by imap.feld.cvut.cz (Postfix) with ESMTPSA id 33B13660904; + Wed, 3 Oct 2012 21:02:02 +0200 (CEST) +Received: from wsh by steelpick.2x.cz with local (Exim 4.80) + (envelope-from ) + id 1TJUCn-000614-Rb; Wed, 03 Oct 2012 21:02:01 +0200 +From: Michal Sojka +To: Jani Nikula , notmuch@notmuchmail.org, + David Bremner +Subject: Re: [PATCH v3 2/9] parse-time-string: add a date/time parser to + notmuch +In-Reply-To: <87391vz8zx.fsf@nikula.org> +References: + <89741ec9a9687fca8b30aa1a4877392d355dd3ce.1347484177.git.jani@nikula.org> + <8739262u4i.fsf@steelpick.2x.cz> <87391vz8zx.fsf@nikula.org> +User-Agent: Notmuch/0.14+23~g9d68aca (http://notmuchmail.org) Emacs/24.2.1 + (x86_64-pc-linux-gnu) +Date: Wed, 03 Oct 2012 21:02:01 +0200 +Message-ID: <87zk43fkgm.fsf@steelpick.2x.cz> +MIME-Version: 1.0 +Content-Type: text/plain +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Wed, 03 Oct 2012 19:02:12 -0000 + +On Wed, Oct 03 2012, Jani Nikula wrote: +> On Tue, 25 Sep 2012, Michal Sojka wrote: +>> Hello Jani, +>> +>> On Wed, Sep 12 2012, Jani Nikula wrote: +>>> Add a date/time parser to notmuch, to be used for adding date range +>>> query support for notmuch lib later on. Add the parser to a directory +>>> of its own to make it independent of the rest of the notmuch code +>>> base. +>> +>> First of all, thank you very much for pushing this towards mainline. +>> This is definitely one of the features I miss in notmuch most. +>> +>> Some comments below. +> +> Thanks for the comments; sorry about the delay in responding. + +No problem :) + +[...] + +>>> +/** +>>> + * parse_time_string() - user friendly date and time parser +>>> + * @s: string to parse +>>> + * @t: pointer to time_t to store parsed time in +>>> + * @now: pointer to time_t containing reference date/time, or NULL +>>> + * @round: PARSE_TIME_NO_ROUND, PARSE_TIME_ROUND_DOWN, or +>>> + * PARSE_TIME_ROUND_UP +>>> + * +>>> + * Parse a date/time string 's' and store the parsed date/time result +>>> + * in 't'. +>>> + * +>>> + * A reference date/time is used for determining the "date/time units" +>>> + * (roughly equivalent to struct tm members) not specified by 's'. If +>>> + * 'now' is non-NULL, it must contain a pointer to a time_t to be used +>>> + * as reference date/time. Otherwise, the current time is used. +>>> + * +>>> + * If 's' does not specify a full date/time, the 'round' parameter +>>> + * specifies if and how the result should be rounded as follows: +>>> + * +>>> + * PARSE_TIME_NO_ROUND: All date/time units that are not specified +>>> + * by 's' are set to the corresponding unit derived from the +>>> + * reference date/time. +>>> + * +>>> + * PARSE_TIME_ROUND_DOWN: All date/time units that are more accurate +>>> + * than the most accurate unit specified by 's' are set to the +>>> + * smallest valid value for that unit. Rest of the unspecified units +>>> + * are set as in PARSE_TIME_NO_ROUND. +>>> + * +>>> + * PARSE_TIME_ROUND_UP: All date/time units that are more accurate +>>> + * than the most accurate unit specified by 's' are set to the +>>> + * smallest valid value for that unit. The most accurate unit +>>> + * specified by 's' is incremented by one (and this is rolled over +>>> + * to the less accurate units as necessary). Rest of the unspecified +>>> + * units are set as in PARSE_TIME_NO_ROUND. +>> +>> Why you round down and increase the most accurate unit? If I want to see +>> emails that were send yesterday, I do not want to see any email that was +>> sent the first second of today. (OK, I know that this is slightly easier +>> to implement) +> +> It's easy to agree that yesterday's messages should not include messages +> from the first second of today. It's not even too difficult to implement +> that. But doing that in this API would feel like rounding 0.6 up and +> getting 0.9999... as a result. +> +> I'll look at adding a separate rounding mode to keep the API generic +> while better support the sole user of the API. + +I agree that the operation I want here should not be called rounding. +Maybe, you can use a term from set theory: supremum or prehaps maximum +(seconds are countable). + +Cheers, +-Michal -- 2.26.2