From: Michal Sojka <sojkam1@fel.cvut.cz>
To: Jani Nikula <jani@nikula.org>, notmuch@notmuchmail.org,
	David Bremner <david@tethera.net>
Subject: Re: [PATCH v3 2/9] parse-time-string: add a date/time parser to
	notmuch
In-Reply-To: <87391vz8zx.fsf@nikula.org>
References: <cover.1347484177.git.jani@nikula.org>
	<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
Precedence: list

On Wed, Oct 03 2012, Jani Nikula wrote:
> On Tue, 25 Sep 2012, Michal Sojka <sojkam1@fel.cvut.cz> 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