Re: approxidate parsing for bad time units

[Jeffrey Middleton <jefromi@gmail.com>]

I'm generally very happy with the fuzzy parsing. It's a great feature
that is designed to and in general does save users a lot of time and
thought. In this case I don't think it does. The problems are:
(1) It's not ignoring things it can't understand, it's silently
interpreting them in a useless way. I'm pretty sure that "n units ago"
is equivalent to "the same time of day on the last day of the previous
month, plus n days."
(2) Though in some cases it's really obvious, in others it's quite
possible not to notice, e.g. if `git rev-list --since=5.dyas.ago` is
silently the same as `git rev-list --since=4.days.ago`.

So I do think it's worth improving. (Yes, I know, send patches; I'll
think about it.)


On Thu, Sep 6, 2012 at 1:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeffrey Middleton <jefromi@gmail.com> writes:
>
>> In telling someone what date formats git accepts, and how to verify it
>> understands, I noticed this weirdness:
>>
>> $ export TEST_DATE_NOW=`date -u +%s --date='September 10'`;
>> ./test-date approxidate now; for i in `seq 1 10`; do ./test-date
>> approxidate "$i frobbles ago"; done
>> now -> 2012-09-10 00:00:00 +0000
>> 1 frobbles ago -> 2012-09-02 00:00:00 +0000
>> ...
>> 10 frobbles ago -> 2012-09-11 00:00:00 +0000
>>
>> Which gets more concerning once you realize the same thing happens no
>> matter what fake unit of time you use... including things like "yaers"
>> and "moths". Perhaps approxidate could be a little stricter?
>
> "Could be stricter", perhaps.
>
> Do we care deeply?  I doubt it, and for a good reason.  The fuzzy
> parsing is primarily [*1*] for humans getting interactive results
> who are expected to be able to notice when the fuzziness went far
> off.
>
> As long as we have ways for scripts and humans to feed its input in
> a more strict and unambiguous way [*2*], it does not hurt anybody if
> the fuzzy parser ignored crufts that it does not understand.
>
>
> [Footnotes]
>
> *1* ... and of course some coding fun and easter egg values. Think
> of it as our own Eliza or Zork parser ;-).
>
> *2* And of course we do.