Allow adding start and end dates to timeframes.txt

[evansiroky]

Describe the problem

The only way to currently indicate that a fare policy would apply on specific dates is to relate the records in timeframes.txt to a service_id found in either calendars.txt or calendar_dates.txt. This however could be somewhat problematic as it may necessitate duplication of all associated data with the service_ids to properly encapsulate how the fare policy is applied.

Use cases

As a transit agency, I would like to promote my "fare free week" in GTFS Fares v2, So that customers can see that transit is free this week, YAY!

Proposed solution

Add columns start_date and end_date to timeframes.txt. These columns would be conditionally forbidden if the service_id was present.

Additional information

Example use case in real life:

Related to #450.

[jfabi]

Hi @evansiroky—new service_ids can be defined (in either calendar.txt or _calendardates.txt) exclusively for use in fares/timeframes. In other words, for weekdays, you could have your normal "weekdays" service_id for trips to be assigned to, and a separate "fare-weekdays" and "free-freeweek" service_ids for timeframes. The Metro-North example on the Fares v2 page highlights this as an option, and we've successfully used this a couple times at the @mbta to highlight times/days with suspended fares. It may be worth calling this out explicitly in the calendar.txt/_calendardates.txt specs.

Does this help with your example, or is there a reason to have trips and fares on the same service_ids here?

[evansiroky]

The creation of new service ids specifically for the fare policy is the problem. It starts to be an invasive exercise that requires changing data outside of the Fares v2 files. This breaks any contract of modularity of being able to edit Fares v2 data without needing to touch the other data.

Sure it's possible to create a new service id and duplicate the rest of the trips and stop times, etc. But that seems like way more work compared to just being able to specify dates that fare policies are active within the timeframes.txt file. Also, being able to set the dates in timeframes.txt enables editing Fares v2 data without needing to change the rest of the core GTFS Schedule data.

[jmchatton]

+1 to this request-- I laid out the details in a reply to @evansiroky on Slack but in essence, since we manage and generate GTFS-static from our scheduling software, we have to create copies of schedules in order to generate different service_id values, which are then assigned to the fare-free periods in the service calendar and come out as such in the static files.

For us it's unintuitive to link the fare rules to the service, when in this context it has nothing to do with the service itself but a period of dates.

[tzujenchanmbd]

The criteria mentioned in Criteria for Independent Publication document might help in considering whether it’s worthwhile to add these fields to support independent publication.

[miklcct]

-1 to this

You can add service_id just for your fare free week. You do not need to change any of the existing service_id in the file.

You can even put a calendar.txt with only your fare free week in your fares package.