Webhook: Making Sense of Timestamps

The events coming in from the webhook interface do not seem to have a consistency one would like. Some of it is a bit comical, in its own way, with events taking place that theoretically couldn’t yet have taken place…

A very simple example of a scheduled run that had four zones in it. I’ve stripped away the date portion of the timestamp just to make it a bit easier to view:

 timestamp                          event type                                                 startTime         endTime
18:00:00Z                      SCHEDULE_STARTED_EVENT                        18:00:02.169Z     18:02:05.169Z
18:00:01Z                      DEVICE_ZONE_RUN_STARTED_EVENT        18:00:01.216Z     18:00:03.216Z     zone 1
18:00:03Z                      DEVICE_ZONE_RUN_STARTED_EVENT        18:00:03.309Z     18:00:25.309Z     zone 2
18:00:13Z                     DEVICE_ZONE_RUN_COMPLETED_EVENT   18:00:01.808Z     18:00:03.808Z     zone 1
18:00:16Z                     DEVICE_ZONE_RUN_STARTED_EVENT         18:00:14.907Z     18:01:00.907Z     zone 3
18:00:25Z                     DEVICE_ZONE_RUN_COMPLETED_EVENT   18:00:04.405Z     18:00:26.405Z     zone 2
18:00:51Z                     DEVICE_ZONE_RUN_STARTED_EVENT         18:00:51.712Z     18:02:04.712Z     zone 4
18:01:01Z                     DEVICE_ZONE_RUN_COMPLETED_EVENT   18:00:16:210Z     18:01:02.210Z     zone 3
18:02:04Z                     DEVICE_ZONE_RUN_COMPLETED_EVENT   18:00:52.224Z     18:02:05.224Z     zone 4
18:02:05Z                     SCHEDULE_COMPLETED_EVENT                   18:00:01.236Z     18:02:04.236Z

There is no property by property documentation available for the various webhook events, so one is left attempting to reverse engineer the individual thoughts of each individual working on the event set - it does come off as though more than one person was doing the work.

It may not seem hugely important, but it's a bit amusing that the start time of the first zone precedes the schedule starting. It's maybe equally amusing to find that strat events have endTime values on them. 

The question at this point would really be: what is the logic by which each of the timestamps (even the event timestamps) are generated and put into the data? What is the rationale behind how each start and end time is determined, and are the dateTime values just wishful thinking, best guesses, or is there an actual methodology being employed? A schedule that is operating sequentially really shouldn't have this behavior, and while the event timestamps bear a sequence, the rest of it leaves a lot of guesswork involved.

It would be good for there to be a documented methodology for the event data. 
It would be good for there to be consistency at the property/field level for each event as far as source and meaning
It would be good for a sequence of events to make sense as to why they fall in the sequence in which they do