Change request for statusInfo : add date time stamps for creation and last update

[Pedro Goncalves]

I propose to add two new optional properties in the statusInfo yaml to deal job creation and last status update
This would be the property created and updated (both of type date-time)

The created is the date time when the job was accepted and the updated is the date time when the job last changed status.

[Francis Charette-Migneault]

I think you can even consider more than only those 2 date-times.
On our side, we report created, started, and finished, since job submission and job execution times can differ more or less in async according to demand. We don't have an updated, but this is a good idea and easy to add.

{
  "jobID": "88dc510f-05b9-4387-a269-501211144a67",
  "status": "succeeded",
  "message": "Job succeeded.",
  "created": "2021-03-02T03:01:22.838000+00:00",
  "started": "2021-03-02T03:01:23.273000+00:00",
  "finished": "2021-03-02T03:01:27.256000+00:00",
  "duration": "00:00:03.983",
  "percentCompleted": 100,
  "links": [ ... ]
}

If OGC can recommend and ensure consistent fields names for those type of details, I would like it!

[Panagiotis (Peter) A. Vretanos]

@fmigneault I think started is a good addition. I you have updated, which is the last time the job status was updated, you don't need finished. When the status is completed, the updated date will be the timestamp when the process finished. Similarly, duration seems unnecessary too since updated-started = duration... no?

[Francis Charette-Migneault]

@pvretano
In our case it was a matter of logging when the "real processing" was finished vs the full process execution, which can lead to more job updates. Often that will be very close to the last update, but there could be noticeable delays (file transfers, killing instances, etc.) that would make a difference. In our case, duration = (finished - started) != (updated - created) if we consider updated the last job update. It is there more as convenience, not a requirement.

Having the 4 times, created, started, finished, updated, allows more precise evaluation of "core" execution time, but I can see how the distinction between the 2 "end" times could be of lesser importance for some.

[Benjamin Pross]

Fixed.