Re: approxidate parsing for bad time units

[Jeff King <peff@peff.net>]

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, agreed. We are really talking about two distinct cases:

  1. An absolute date ("the 3rd of June", "last tuesday") whose exact
     location may need to be inferred from the context of the current
     date.

  2. A relative unit difference from the current time ("7 days ago")

However, I'm not sure that the word "ago" is always present when
choosing the latter. For example, you can say "7 days" and approxidate
will treat it like "7 days ago". Nor is it simply using a unit like
"days". You can even say "7 tuesdays" to go backwards that many Tuesdays
(e.g., the 24th of July from today).

So you can use "ago" as a sign that you are definitely in case (2), but
cannot assume that its absence means you are in case (1).

That means we can catch "3 dasy ago" as nonsensical, but not "3 dasy",
as the latter simply looks like "the 3rd" from approxidate's
perspective. Still, something is better than nothing, and it means if
you are careful to always say "ago", you can catch some errors (of
course, you might typo "ago"... :) ).

> My first thought was just to make it an error if the string ends in
> "ago" but the date is parsed as a day of the month. You don't actually
> have to come up with any typos to blacklist, just keep the "ago" from
> being silently ignored. I suspect "n units ago" is by far the most
> common use of the approxidate parsing in the wild, since it's
> documented and has been popularized online. So throwing an error just
> in that case would save essentially everyone. I hadn't even realized
> it worked without "ago" until I looked at the code.

Yeah, I think that would work, and would provide some safety. And it
shouldn't be too hard to implement.

> If that doesn't sound like a good plan, then yes, I agree, it'd be
> tricky to catch it in the general case without breaking things.
> (Levenshtein distance to the target strings instead of exact matching,
> I guess, so that it could say "did you mean..." like for misspelled
> commands.)

Gross. :)

-Peff