In core Jenkins (for non-pipeline jobs) the duration of a run is calculated and stored before RunListener.fireCompleted(Run, Listener) is invoked whereas in workflow-job-plugin the duration is calculated after RunListener.fireCompleted is invoked but before FlowExecutionListener.fireCompleted is invoked.

Is this intentional?

Are you implying that, as a plugin developer, I should I be creating a RunListener<AbstractBuild> and a FlowExecutionListener<WorkflowRun>? I would guess not since the net effect would be somewhat different in timing calculations. In other words, FlowExecutionListener's duration of Run would effectively increase the time cost of running all of the RunListeners.

WorkflowRun code

Core Jenkins Run code

In short, this PR gives us better metrics and a consistent interface to get build time metrics.

Scenario:

MyRunListener implements RunListener.onCompleted() to do something with duration. Here are the results before this change in MyRunListener.onCompleted: 

WorkflowRun.duration: always 0

hudson.model.Run.duration: calculated based on start and end time.

So, essentially, there is an inconsistency in the expectation of duration being available and the fact that a RunListener would need to calculate the duration puts the RunListener in a situation where they may not be calculating it in a consistent moment.