Re: approxidate parsing for bad time units

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeffrey Middleton <jefromi@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]