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