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 date is
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
Jeffrey Middleton jefr...@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'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
4 matches
Mail list logo
