bring run_events.txt time fields into consistency with existing GTFS nomenclature

[safrazier17]

run_events measures time using two fields: event_time and event_duration. This is at odds with how time is measured in GTFS and related specifications where time is consistently recorded using the starting time and ending time. It doesn't seem like there is a good reason to deviate from this practice and measure time using a starting time and duration of the event in seconds.

Propose:

• renaming the event_time field start_time
• deprecating the event_duration field
• adding an end_time field to replace duration

[jeffkessler-keolis]

I recall from the working group conversation this was done intentionally.

Some events in a run require preservation of times, whereas others require preservation of duration. An example may be a CBA-mandated 40-minute lunch, for which a delay upon arrival would amount to an equivalent delay upon departure. Other events are more fluid such as a lengthy rest period that can be shortened when the prior activity is delayed. This flexibility could be determined at a user/application level based upon the event_type.

While programmatically both approaches are identical, the adopted approach's lack of parity with the standard's other time conventions draws attention to the distinction and better provisions for a potential extension of minimum_duration.

[skyqrose]

Oh, interesting!

I think I still prefer start/end_time, though. Some events don't have that requirement, and having the _duration field for all events is awkward. The minimum_duration field would work just fine at conveying this requirement if it were used alongside start/end_time.

[safrazier17]

I recall from the working group conversation this was done intentionally.

Some events in a run require preservation of times, whereas others require preservation of duration. An example may be a CBA-mandated 40-minute lunch, for which a delay upon arrival would amount to an equivalent delay upon departure. Other events are more fluid such as a lengthy rest period that can be shortened when the prior activity is delayed. This flexibility could be determined at a user/application level based upon the event_type.

While programmatically both approaches are identical, the adopted approach's lack of parity with the standard's other time conventions draws attention to the distinction and better provisions for a potential extension of minimum_duration.

Thank you for this reminder, Jeff. That does ring a bell. It seems to me that in the v1.0 spec we have some suppressed typing of events (which I recall in our discussions did become a bit of a rabbit hole). It seems like it may be a good time to revisit this and surface some of those different event types.

From Jeff's post:

• end on time (to me this means "regardless how late the event begins, it is afforded no additional time beyond the scheduled end time; if the actual start time is later than [x] seconds of the scheduled end time it is skipped completely")
• minimum duration (to me this means "regardless how late the event begins, it cannot be eliminated or truncated further than [x] seconds") ** This allows for the possibility that something either (1) needs to occur at its full scheduled duration or (2) the fluid case Jeff described where the minimum duration is perhaps less than the scheduled time between start and end due to some schedule padding

Other thoughts? That could already be a substantial improvement of our handling of run_events in v2.0 even if we stopped there.

[safrazier17]

Maybe in addition to minimum duration, there is also fixed duration (i.e. the case 1 under minimum duration above, but also accounting for a case in which regardless of how early an event begins, it still is capped at that scheduled duration and cannot exceed it).

[BTollison]

I like this idea, with minimum_duration you can avoid accidentally violated an agreement. I can't think of a scenario where fixed_duration couldn't be covered by minimum_duration though.

[jeffkessler-keolis]

While I agree the two are functionally equivalent from a programmatic perspective, I think my preference remains for the start_time and duration fields vs start_time and end_time as it makes it much easier to inspect the output files for validation.

For example, it's much easier to detect an anomaly in event duration (particularly if all events of a given type are supposed to be of a certain duration) vs if it's simply start/end times for which the duration would need to be calculated. Likewise, if a duration and minimum_duration field are defined, any potential discrepancy or error is much easier to review vs needing to compute the duration value as another step.

[safrazier17]

I like this idea, with minimum_duration you can avoid accidentally violated an agreement. I can't think of a scenario where fixed_duration couldn't be covered by minimum_duration though.

I suppose it depends on whether or not you interpret minimum duration as meaning (A) "if the event is not truncated, it should be exactly the scheduled duration" or (B) "if the event is not truncated, depart at the scheduled time." Because in the event that an event is started early, A and B will not be the same. Specifically, A would mean an earlier end to the event than B. fixed duration as I pitched it would remove that ambiguity, because it would mean exactly case A. And then case B could be covered by minimum duration. That was, in any case, the proposed use case

[skyqrose]

I just opened #60, which I think really needs an end_time field rather than duration. Column(s) for minimum_duration, end on time, etc could be added as additional fields in that file, depending on what people decide here.

[safrazier17]

Closed, as the substance of the proposal is now included in #60.