Calculation of target date/time and remaining time in fields "Time to SLA"

Issue #183 closed
Markus Hein created an issue

Hallo Tuncay,
do you have any documentation about the calculation of the target date/time and the fields "Time to SLA"?
Can you explain the difference between these values in following screen shot (today is 16.3.2016) please:
TTS_20160316a.JPG colleagues do not understand why only 5 days are remaining from today (16.3.2016) until 11.4.2016, for a SLA value of 16 days...
...or is there a bug?
You will find our definition of working hours as attachment, relevant non-working days are: 25.3.2016 and 28.3.2016.

Thanks in advance!

Comments (22)

  1. Tuncay Senturk repo owner

    Hi Markus,

    I think it should be 15d 7h 59m 51s and the very left part can't be seen because of the width.
    Could you please open developer tools by right clicking the "5 DAYS ..." (green) section and click "Inspect". The original value will be seen there.

  2. Markus Hein reporter

    15 days would be what I expected, too...
    The result in the "developer tool" is following:
    <div id="tts-timeToSla-countdown-customfield_12301-1" class="tts-
    timeToSla-countdown tts-timeToSla-countdown-paused aui-lozenge aui-
    lozenge-success hasCountdown" deadline-val="1458662455166"
    slavalue="7680" workingtime-start="1458201604166" until-
    timestring="127h 59m 51s" workingtime-till="1458230404166"
    ispaused="true" isnonworkingday="false" isnonstop="false" day-
    counter="5" notmuchtime="20" working-minutes="480">5 Days 7 Hours
    59 Minutes 51 Seconds</div>

    --> seems to be 5 days...

  3. Tuncay Senturk repo owner

    That's weird, I'll try to reproduce.
    By the way is this intermittent or are you seeing this bug in every issue (for the SLA with 16d)?

  4. Markus Hein reporter

    It seems to me, that this occurs for all SLA definitions with a SLA value defined in days:

    I'm not sure, but I think, that this worked correctly with version 5.11.0 (5.10.0)...

  5. Tuncay Senturk repo owner

    Hi Markus,

    It is hard to reproduce. Could you please attach all your configuration including SLA definition, working hours, nonworking days?


  6. Markus Hein reporter

    Hi Tuncay,
    at the moment we have 23 SLA definitions for the same workflow (actual we only use this one workflow for all customer support project for issuetype bug. With JQL we "assign" the different SLA values (complete description) to the different projects (=customer), e.g. "project in (proj1, proj2,proj3). And a short information to the naming of the SLA definitions (e.g. "SLA-2b2d"): the first number "2" shows the priority, the letter "a" means "time to first action", "b" means "time to resolution". The next number and letter stand for the SLA value (e.g. "2d" --> two days)...
    All SLA definitions follow the same principle, so I add the screen shots only for one pair for our demo project priority "3" ("Medium" - in German: "Mittel")
    Here are a lot of screen shots for you ;-)

    I hope, you can reproduce the problem with this information...
    Otherwise, we could set up a conference call (Lync)

    greetings, Markus

  7. Tuncay Senturk repo owner

    Thanks for the comprehensive docs, I'll soon try to reproduce and understand what's going on?

  8. Tuncay Senturk repo owner

    Finally I got the problem, this is "short format" display problem.
    As a work around please switch to "Long format" and you'll see that it works.
    In the meantime I'll work on it and fix ASAP.


  9. Tuncay Senturk repo owner

    Hi again Markus
    In short format it displays around 8 days, but stops counting fter working hours. Starts back in next day's working hour interval.
    But I know it is annoying to see 8d rather than 18d.

  10. Markus Hein reporter

    Hi Tunkay,
    It looks very strange to me, that the change of the display format "Time format" also changes the calculation routine!
    Maybe it would make sense to add a parameter for the calculation routine...
    I would like to use the short format...
    Okay, now I switched to "Long format", run the Report for existing Issues and re-indexed the system.
    The presentation in the issue screen seems to work as expected....

    But now (maybe also before the change of the format), I get strange results in the Issue Navigator (filters):

    I do not understand the results of the selection to greater- / lower equal some days...
    1st picture: >= 5d: why is SP_DEMO-38 also included?
    2nd picture: <= 6d: I miss some issues, see previous picture
    3rd picture: one more day in the selection (<= 7d) and SP_DEMO-38 appears in the list?
    and so on...

    Please could you explain this...
    And please have a look on the sorting - I don't understand this, too

    Thanks in advance,

  11. Tuncay Senturk repo owner

    Hi Markus,

    You won't need to use Long format, it is just a javascript bug and I fixed that. It is waiting for the release. (For counter 1d = 24h, but after the release 1d = 9h, depending on your working days)
    Searching problem is really hard to tell and it is not related with time format.
    When you search with JQL JIRA searches results from its index, and here the index is the SLA end date. SLA End Date can be a day which is 5 days from now, but if you count working days it can be 2 days. Since I can not index time strings all the time (because they change every second) I index end date as the indexing value.

    Sorting is similar, but I will have a focus on all of them later. In the meantime you can use SLA Report for detailed info.

    I hope I was clear,
    Thanks for your understanding.

  12. Markus Hein reporter

    Thanks for the correction...
    I'm in vacation next week and will be back on March, 29th.
    Then I will test the new version and will continue to try to understand searching and sorting...
    At the moment I still don't get it, even knowing that the "calculated end date" (based on working days) is used for the index.
    bye for now,
    Greetings, Markus

  13. Markus Hein reporter

    Hi, Tuncay, I'm back again...
    We installed the new version 5.13.0, but I do not understand the change at all:
    using the "long format"


    I get following result:


    This is the same as with 5.12.0.
    Changing to "short Format" and after re-indexing, I see following:


    But I expected "8d 0h 0m 22s", as shown in the sample string:


    --> the "short format" seems to convert the "days" to hours and adds them to the other hours...
    --> now there is almost no difference to the "Shorter format".
    Was this intended by you?

  14. Markus Hein reporter

    Now I compared the filter results with the "SLA Report". For both I used the same JQL "project = SP_DEMO AND issuetype = Bug AND status = "In Work" AND priority = Mittel AND "SLA - To Resolution" is EMPTY ORDER BY cf[12301] DESC".
    As you told me, that you use the expected target date/time, I do not understand the difference in both lists:


    ...and I can't understand why the "order by"-clause seems to be ignored by the filter:


    Please help!

    Thanks, Markus

  15. Tuncay Senturk repo owner

    Hi Markus,

    • "Short format" should only convert days to t, hours to h, and so on. You're right, and we fixed the bug, waiting for the release.
    • SLA Report sorting fails because of your date format. Actually, we designed it to give exact date format dd/MMM/yyyy hh:mm a (as a sample 20/Mar/2016 08:20 AM), so that client side sorter would sort it against this format. However, we failed that complete date format in JIRA depends on JIRA's general settings, and that's why your format is different, and sorting is somehow erroneous. We will fix this as well.
    • For sorting in issue navigator, we will deep dive.


  16. Markus Hein reporter
    • changed status to open

    Hi Tuncay,
    sorry, but also in version 5.14.0 I get the long presentation instead of "short format" within the issue:

    In the issue navigator it works fine:


    And I got an interesting result, when the "time for first action" failed and I continue with status "in work":


    Please help...
    Thanks, Markus

  17. Tuncay Senturk repo owner

    Hi Markus,

    Time format does not affect counters, this is by design. Ticking time with suffix "s" was confusing, and we decided to exclude time format for counters.

    If you do not have the same usability decision, you can always share your comments with us.

  18. Log in to comment