trip_duration and vehicle reservations

[jfh01]

Should the trip_duration value of the /trips endpoint include the time time between reservation and trip start (e.g. walk time)? In the context of rideshare, the data about time between request and arrival would be very important.

[jfh01]

Two suggestions to clarify this:

1. Remove trip_duration. It's duplicative of start/end time.
2. Add optional request_time field which would apply to reservations / rideshare requests (future).

[alexdemisch]

One way to capture this would be to use a combination of the Status Change and Trips APIs. Once a user reserves a device, this should create a "reserved" Status Change event with a timestamp. This can be the reservation time. Once the device starts moving, then the trip itself has started, and this can be the trip start time in the Trips API.

[jfh01]

My gut is that many other cities will not have the capacity to use status change data in the way that LA is planning to. Those folks will likely be focused on non-real time retrospective reporting on trips. Having information about reservation/request time in /trips endpoint will be helpful for these cities.

[aickin]

Remove trip_duration. It's duplicative of start/end time.

Just FYI, I submitted a PR for this suggestion in #52.

[hunterowens]

Fix for this is now in #125. Closing.