Active Time display doesn't account for clock differences and can be inconsistent

[itsmojo]

The Pod Setting's "Active Time" display isn't actually based on the timeActive value returned from pod on each response and thus can show inconsistent values. Due to the pod's internal clock inaccuracies, the displayed value can be different from the "Read Pod Status" command's "Pod Active" display (which actually displays the actual pod reported timeActive value) and can disagree with the "Expires" / "Expired" display (which is updated dynamically based on each pod's timeActive value returned) as shown in the following example.

The Read Pod Status "Pod Active" display shows that the pod is reporting that it has been active for 3d, 1h, 3m which disagrees with the Pod Setting's "Active Time" display that says the pod's active life was only 3d, 0h, and 59m. Also the Pod Setting's "Expired" display indicates that the pod expired over a hour ago at the time these screenshots were taken (and which was confirmed by the 1 hour "Expiration advisory" beep that had just occurred a few minutes prior), but the "Active Time" value of 3d, 0h, 59m state that an hour has not yet passed since the pod nominal 72 hour expiration. So in this example, the pod's clock was about 4 minutes too fast over 3 days (which is pretty typical value) and the "Active Time" display is disagreeing with two other displayed values as well as the expiration advisory alarms that are all based on the pod's notion of time.

A better behavior would to simply compute the displayed "Active Time" using the dynamically adjusted podState.expiresAt variable (which already accounts for pod clock differences) instead using the fixed and never adjusted podState.activatedAt variable or to have Loop save & display the actual timeActive value as returned from the pod in each response as a new persistent podState state variable.

[ps2]

Displaying actual activated at time resolves this: #677