On Mon, Sep 10, 2012 at 02:07:02PM -0700, Jeffrey Middleton wrote:
> As you mentioned, parsing "n ... [month]", and even "...n..." (e.g.
> "the 3rd") as the nth day of a month is great, but in this case, I
> think "n ... ago" is a pretty strong sign that that's not the intended
> behavior.
Yeah,
As you mentioned, parsing "n ... [month]", and even "...n..." (e.g.
"the 3rd") as the nth day of a month is great, but in this case, I
think "n ... ago" is a pretty strong sign that that's not the intended
behavior.
My first thought was just to make it an error if the string ends in
"ago" but the
On Thu, Sep 06, 2012 at 02:01:30PM -0700, Jeffrey Middleton wrote:
> 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
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 wa
Jeffrey Middleton 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
5 matches
Mail list logo
