Change event_time definition to require correct ordering

[rf-]

This proposal reflects the consensus of the status change ordering/uniqueness breakout group that it's reasonable to ask providers to construct an accurate and causally-consistent timeline of status
change events. This change will improve API consumers' ability to understand the ordering and timing of events in the status changes API.

See the notes from the first breakout group call for a little bit more context.

Is this a breaking change

• Yes, breaking
• No, not breaking
• I'm not sure

Provider or agency

• provider
• agency
• both

[rf-]

An open question here is whether we should also update the start_time and end_time fields on trips to use the same language. I left it out for now since I didn't want to go past the scope of the discussion on the call, but it would probably make sense to be consistent.

[marie-x]

This will definitely affect Agency, as the data collected via Agency is made available via Provider.

[marie-x]

Seems weird that I can change the check boxes randomly

[toddapetersen]

This will definitely affect Agency, as the data collected via Agency is made available via Provider.

Agree Max... Need to put the brakes on this until we can sync with Agency changes. It is probably time we re-unite the two API's into a single process anyway...they were never meant to be separate.

[marie-x]

Agree Max... Need to put the breaks on this until we can sync with Agency changes.

It's not really a code change, though, it's a semantic change if I understand correctly. I'm okay with it as-is. I just wanted to make a note, and update the Agency wording if needed.

I would be curious to hear if the breakout group considered Agency and its quasi-real-time event-reporting requirements. Were there meeting minutes that I missed? [EDIT: Found the meeting minutes]

[rf-]

We had consensus about this change on the Provider call today—@toddapetersen and @Karcass, do either of you still have any concerns?

[marie-x]

@rf- works for me