Re: approxidate parsing for bad time units

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 6, 2012, 20:36 UTC
Message-ID: <7vehme3n49.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAFE6XRFgQa10vTWXfxRG53W6K4U=VGqpK5sQwH7xp9GfKd=2Uw@mail.gmail.com>

Jeffrey Middleton <jefromi@gmail.com> writes:

Show 14 quoted lines

> 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.