Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-1160

The build time descriptions aren't accurate enough

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: core
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:

      Description

      Our builds typically take around 90 minutes, but hudson seems to round this
      figure down to the nearest hour, so that all our builds are reported as taking
      '1 hour'. Looks like this is been done in Util.getTimeSpanString. Perhaps this
      method could take two largest time units to come up with the description, eg '1
      hour and 31 minutes' or '1 minute and 10 seconds'?
      Thanks

        Attachments

          Activity

          Hide
          dwdyer dwdyer added a comment -

          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"?

          Show
          dwdyer dwdyer added a comment - 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"?
          Hide
          dwdyer dwdyer added a comment -

          I've implemented more precise descriptions in revision 1.46 of Util.java
          (Hudson 1.177)

          Show
          dwdyer dwdyer added a comment - I've implemented more precise descriptions in revision 1.46 of Util.java (Hudson 1.177)

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            ajk52 ajk52
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: