I agree with this in principal. I think there are a few of aspects that need
to be agreed on first though.
Firstly, looking at the current getTimeSpanString method I see one problem: it
is based on the rather dubious premise that there are 360 days in a year (12
months of 30 days). A change to use more precise time strings would highlight
that inaccuracy in cases where a timespan is longer than a year (possibly the
time since last build failure could be this long). The root of the problem is
the use of months. A duration of 2 months 6 days would mean 66 days but this
is not necessarily clear since "1 month" is not a well-defined quanity. I
think we should drop the "month" unit completely and either replace it with
weeks, or don't have a unit between years and days. So the time strings would
either be "2 years 9 weeks" or "2 years 65 days". I prefer the latter.
Secondly, for durations of less than a minute, I don't think that it is
necessary to go to a second unit. In the context of Hudson, a time of "57
seconds 234 ms" is not any more informative than "57 seconds".
Finally, the use of a secondary unit makes the strings a lot longer. Do we
need to abbreviate them? And, if so, which is better? "25m 35s", "25min
35sec", or "25:35"?