Time estimates format not always respected

XMLWordPrintable

    • 5
    • 9
    • Severity 3 - Minor
    • 1

      If you set the time format for time tracking to hours, for some entries the format is not respected.

      Repro steps:

      1. Set time format to hours and enable time tracking for a project.
      2. Create an issue and enter 576.18h as the original estimate.
      3. The time displayed is wrongly as 576h 10m when the expected result is 576.18h

      Notes:
      Anything that is more than two decimals after the divide (X minutes divided by 60) will be shown as minutes. In other words, multiplication of 3 like 3m/6m/9m/12m will all be shown as an hours-decimal format. Otherwise, it will be shown as an hours-minutes format instead.

      Additionally , Jira stores time tracking values in seconds. When you enter a value like 66.6h in the UI:

      1. Jira interprets this as a decimal number of hours.
      1. Converts that decimal to seconds.
      1. Later converts the seconds back into hours and minutes for display.

      Due to floating‑point rounding during this conversion, some decimal values lose 1 second. When Jira then formats that to hours/minutes (and drops leftover seconds), this becomes a 1‑minute difference in the UI

      Example : 66.6h66h 35m

      What you enter in the UI

      • Original estimate: 66.6h

      What we see via the REST API using <baseurl>/rest/api/2/issue/KEY?fields=timetracking
      {{}}

      "timetracking": {  "originalEstimate": "66h 35m",  "remainingEstimate": "4.05h",  "timeSpent": "2m",  "originalEstimateSeconds": 239759,  "remainingEstimateSeconds": 14580,  "timeSpentSeconds": 120 }

      {{}}
      What this means

      • Mathematically, 66.6h should be:
        • 66.6 × 3600 = 239,760 seconds → 66h 36m
      • Jira is actually storing:
        • originalEstimateSeconds = 239,759 seconds
      • 239,759 seconds = 66h 35m 59s, which Jira then displays as 66h 35m (it drops the remaining 59 seconds when showing whole minutes).

      So Jira is short by 1 second compared to the exact 66.6h conversion, which shows up as 1 minute less in the UI. The application should fix this. 

            Assignee:
            Unassigned
            Reporter:
            Alejandro Conde Carrillo (Inactive)
            Votes:
            18 Vote for this issue
            Watchers:
            24 Start watching this issue

              Created:
              Updated: