[TW-681] Relative date values should require user is unambiguous

[taskwarrior]

Cory Donnelly on 2010-08-04T13:08:02Z says:

In the same way that (at)task l@ generates this message:

$ task l
Ambiguous command 'l' - could be either of list, log, long, ls

using an ambiguous relative date value should throw a similar error message.

Consider:

$ task add Foo wait:1m
Created task 16.

Here, 'm' user could mean 'm' to mean 'minute' or 'month'.

[taskwarrior]

Migrated metadata:

Created: 2010-08-04T13:08:02Z
Modified: 2014-02-09T02:06:33Z

[taskwarrior]

Federico Hernandez on 2010-08-05T07:02:24Z says:

I will comment when sitting in front of a real keyboard.

[taskwarrior]

Paul Beckingham on 2010-08-05T07:30:10Z says:

Just a note: Taking one example, "yearly", I wanted to be able to accept words that make sense. In this case "yearly", "years", "yrs" are common ways of entering a number of years. In addition, I wanted the ultimate abbreviation to work - "y". This means there are 4 words that are accepted - "yearly", "years", "yrs" and "y", which makes "y" not ambiguous, but a direct match. "year" is ambiguous. Similarly for all the other durations.

You may have a point about "m", but this was all deliberate.

[taskwarrior]

Cory Donnelly on 2010-08-05T08:19:01Z says:

I should have been more clear -- I think it's perfectly appropriate to allow all of your examples to resolve to "years" -- "yearly", "years", "yrs" and "y" are all different commands, but unambiguously resolve to the same period. "m" is the specific example that confused me as a user.

As an aside, whose idea was it to implement "sennight?" :)

[taskwarrior]

Paul Beckingham on 2010-08-05T17:12:17Z says:

I see, so it's just the 'm'? Would simply taking that one out work for you?

As for "sennight", that was me, and it's a clue as to what book I was reading at the time.

[taskwarrior]

Federico Hernandez on 2010-08-08T20:19:33Z says:

I see the point in just using 'm': it is shorter. And there weren't minutes in task before.

Now I still would prefer to keep m for the month and either use mi, M or mm for the minutes or even 0m30m, omitting years, days and hours plus seconds from a time period that is normally given with P0Y3M10DT5H30M13S with P for period and T for separating "date" values from time values.

[taskwarrior]

Federico Hernandez on 2011-01-08T14:31:49Z says:

Needs more thinking.

[taskwarrior]

David Patrick on 2011-01-08T16:46:47Z says:

I think this one is a clear-cut case. Ambiguous = FAIL did you mean (mi)nute or (mo)nth ?

if we dealt in "miles" "mi" might be ambiguous too, but we don't, so it isn't.

[taskwarrior]

Paul Beckingham on 2011-08-24T02:52:21Z says:

David is right. 'm' is ambiguous. 'mi' and 'mo' are not. Support for 'm' is removed.