Simpler Duration entry (Read 857 times)

I was wondering if it would be possible to add some heuristics to the Duration field. If I enter "63:00" in the duration field, it should be able to accept that as 63 minutes, rather than me having to enter "1:03:00". Honestly, it would be nice if it would accept "63", and assume that it's neither 63 seconds, nor 63 hours, particularly if I've already specified a distance of 6.36 miles (alright, I'm slow...). Even if you can't look at the distance, about the only things that people might do regularly that would be confusing would be 1, 1:*, 2, and 2:* (At least I'm assuming that there aren't that many people who run 3 hours at a time frequently (but honestly, I'm also guessing that there aren't that many people entering sprints of less than 4 minutes)). Anyway, thank you very much for the log. It helps me get out and run.

Sorry, I went looking, but I managed to miss that. I'll address the one complication that I see below. Anyway, well, my suggestion is really two suggestions. The first one is EASY. Accepting "63:00" as 63 minutes. If there are no colons, it's seconds. 1 colon => mm:ss. 2 colons => hh:mm:ss Just accept numbers from 60-99 (Heck, maybe there are people who think about 150 minutes rather than 2.5 hours. Let them type "150:00"), div mm by 60, add to the next higher unit, and mod mm by 60. Repeat for seconds. You could even allow "63:", "1:3:", and "1::" (to round a bit) without any ambiguity at all (RA currently accepts "1:3:0", but none of my three examples). The second one gets more complex, but I really don't think it's such an issue unless we have ((a lot of both (ultra-marathoners who don't care about the seconds) AND (sprinters)) AND (can't look at the distance to determine what was meant)). If we can look at the distance (which we clearly do in order to determine speed), pick the parsing that implies I'm running humanly rational times. No one here is running faster than 3 minute miles, so a duration of "63" for 6.36 miles can't be 63 seconds. I'm wildly assuming that no one here is running 10 hour miles, so 63 hours is also right out. If you're worried about people who don't enter a distance, but do enter a time, well, how many of them are there? I'd expect most people enter both, and that more people don't enter time, than don't enter distance. So even for the (I'm assuming) 3 people who enter time but not distance, I'd expect most times would be between 10 minutes and 5 hours. But even if you don't want to make that assumption, you could require one or more of {no time, fully qualified time, distance}, and not have to guess. The only possible nit that I see from the previous discussion is the person who doesn't want to have to enter colons. But even that's deal-with-able. If you get a Duration without colons of 4 or more digits, parse it by inserting colons from the least significant figure. I suppose there's still some ambiguity if he's entering 3 digit times. Does anyone enter a lot of times of less than 10 minutes and want this? I suppose I'm saying it's possible to give this to most people (I'm making several unsubstantiated assumptions about the RA population, I admit) and not make anything worse for the minority. Am I missing something? Be well.

Sorry, I went looking, but I managed to miss that. I'll address the one complication that I see below.

No worries. I like thinking through this...

Are you a programmer? Because you sure sound like one. Thank you for the awesome break down. I've recorded it in my feature request database. I will try to work it in for the log over haul. If you are a programmer and don't want to wait, you can write such a function and I can integrate it into the system. eric

Hi, You can write it in any language you want, preferably C/C++/C#/Java. I would imagine the function prototype would be: decimal ConvertTime(const string& strTime) where strTime is the time expressed as a string decimal is the converted time expressed in fractional seconds Thanks for considering it! eric

Well, I wrote it in java (using int convertTime(String duration, Double distance) ), but I kept finding places where the right thing to do involves something happening on the page, using, I'd assume, javascript. IE, I'd say that when there's a valid parsing, it should be shown on the page, in black, in the canonical form, next to the entry box so that the user knows it's right. Kind of like how you give Pace already. When the user doesn't enter a distance, it simply falls back to what's there now (except that it will accept "6:", or "2::"). Then there's two classes of error. To my mind, both should put something in bold red next to the entry box so the user knows something is wrong. When there is no rational parsing (say 5 miles run in "6:0"), the user should see "0:06:00" in red. When parsing is not possible (say "1:0:0:4", or "hour"), the user should see "Can't understand "+string in red. I tried to make it always possible to simply fill in to the right to get the canonical form, so if you went a mile in 8 hours, you can simply add "::" to the end (because "8" or "8:" will translate to 8 minutes) , but if someone really thinks that they ran 5 miles in 40 seconds, this will prevent them from entering that... How should I get you the code? Should I just post it here? The parser is about 200 lines (though most of that is comment or whitespace), and the excuse for a tester is around 100. Be well. And thanks, this was interesting.

I tried this in Google Translate but I still cannot understand it. I'd better stick to what I do best (and that is not programming!). Thanks guys - I'm sure the end result will be neat. Neil UK