Re: approxidate parsing for bad time units
- From
- Jeffrey Middleton <jefromi@gmail.com>
- Date
- Sep 6, 2012, 21:01 UTC
- Message-ID
- <CAFE6XREG5-gwjzvyP9r_hfyY3bWSV2=Bjv9ZbXkejXQRoqYERA@mail.gmail.com>
- In-Reply-To
- <7vehme3n49.fsf@alter.siamese.dyndns.org>
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:
Show 35 quoted lines
> 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.