Get-DBAAgentJobHistory adding an hour on to the enddate and duration

[NickGuy1]

#issue
Issues seen with duration and enddate adding an extra hour on to some jobs
tested on dbatools verion 0.9.490

#reproduce
I've been able to reproduce this using the logic from Get-JobHistory
$DurationInSeconds = ($execution.RunDuration % 100) + [int]( ($execution.RunDuration % 10000 ) / 100 ) * 60 + [int]( ($execution.RunDuration % 1000000 ) / 10000 ) * 60 * 60

where runduration in this case is the equivalent of 1 hours 56 minutes 14 seconds

$runduration = 15614

The current function logic returns:
Enddate: 25 October 2018 03:02:15

$durationinseconds = ($runduration % 100) + [int]( ($runduration % 10000 ) / 100 ) * 60 + [int]( ($runduration % 1000000 ) / 10000 ) * 60 * 60
(get-date -date "2018-10-25 00:06:01.000").AddSeconds($durationinseconds)

using logic from Rob's post
https://sqldbawithabeard.com/2016/09/12/converting-sql-agent-job-duration-to-timespan-using-powershell/

[timespan]$durationinseconds2 = ($runduration).tostring().padleft(6,'0').insert(4,':').insert(2,':')
(get-date -date "2018-10-25 00:06:01.000").AddSeconds($durationinseconds2.TotalSeconds)

returns
25 October 2018 02:02:15

which is the expected result based on sql agent job history

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If you would like this issue to remain open:

• Verify that you can still reproduce the issue in the latest version of dbatools
• Comment that the issue is still reproducible and include:
  • What version of dbatools you reproduced the issue on
  • What OS and version you reproduced the issue on
  • What steps you followed to reproduce the issue

[stale]

This issue has been automatically closed because it has not had activity in the last three months. If this issue is still valid, please add a comment

[SQLGB]

I observed this issue today with build 0.9.777 on at least one server out of 100 that I queried, and was wondering why this bug report appears to be closed as stale / won't fix?

[SQLGB]

Thanks for re-opening. I re-checked my results; in a query of one job on each of 86 instances, 16 reported incorrect Duration and EndDate. But it's not always a one hour difference; sometimes it's a difference of just one minute.

[SQLGB]

As @NickGuy1 mentioned in his original bug report, the formula for $DurationInSeconds returns incorrect values in some cases. If the digit in the "tens" position of either seconds or minutes (possibly hours also) is a 5 and any other digits are greater than zero, an incorrect result is returned. Input of "50" seconds returns output of 50 seconds; input of 51 seconds returns output of 111 seconds (instead of 51). Input of 50 minutes returns 3000 seconds; input of 51 minutes returns 6660 seconds (instead of 3060).

[SQLGB]

Submitted pull request.

#5157

[potatoqualitee]

fantastic, thank you, @SQLGB!