Easy to mistake "m" duration prefix for minutes when it actually means months

[aljelly]

It's a very easy mistake to type something like this: timew start 5m to mean "begin tracking something that started 5 minutes ago".

But in fact, it actually means "begin tracking something that started 5 months ago".

(In that particular example, you would most likely be prevented from tracking that time due to overlapping intervals, but in other situations this could be a big mistake.)

What if, when you first use "1m", Timewarrior asks whether you mean "1min" (minutes) or "1mo" (months)? That will then become the default interpretation when you use "1m" the next time.

(People who are used to typing "m" for months and "min" for minutes could continue to do so, while people who are used to typing "m" for minutes and "mo" for months would be saved from making a potentially disastrous mistake.)

[lauft]

I see three solutions in this issue:

1. Make "m" ambiguous, i.e. require either "mo" or "min" to be entered
2. Make (time) parsing configurable, i.e. define "m" as an alias for minute/month
3. Add safeguard to prevent entering of unusual large durations (e.g. > 1d)

While 1) and 2) will require adaptations in the parser which is also used in taskwarrior (and thus we have to be careful about side-effects), 3) should be timewarrior only.

[pbeckingham]

I would suggest option 1, being done in the client. Validate any {{\dm}} with a warning and convert it to {{\dmo}}.

Because multiple projects share date parsing code, I know from experience that simply removing 'm' as a supported unit (your option 1) has caused a lot of problems in the past. I temporarily removed it, and then put it back after problems syncing data between software versions meant that data that was once valid was no longer valid.

This can be done properly if all the clients auto-upgrade from 'm' to 'mo', thus cleaning the old data in time. Putting checks in the client as an additional layer would stop new bad data getting stored, as well as alerting users to the potential mistake.

Making 'm' configurable (Option 2) would cause problems when two clients with different configurations make assumptions or read each other's data.

Option 3 is independently a good idea.

[cjbarroso]

I'm very very late to this discussion, but I want to add an opinion for the future. How many times the users need the enter months-long intervals? how often they need to enter minutes? There is your answer, from usability POV.

[ddombrowsky]

I'm sorry this is closed. I've been using timewarrior for years and I still occasionally make this mistake. Shouldn't both "months" (or maybe "mons") and "mins" require multiple characters?

[lauft]

@ddombrowsky the issue is not closed, but also currently not worked on. I just deleted the backlog milestone (because everything is "backlog" if it is not part of a milestone).