MobilityData
FeedExpirationDateNotice doesn't make any difference between 7 days and 30 days expirations
FeedExpirationDateNotice checks for both 7 days and 30 days expiration without any distinction.
I don't feel strongly on either solution but it should :
- only check for 30 days expiration and not mention 7 days.
- Have a warning for 7 days and info for 30 days.
Thanks for opening this issue @gcamp. This rule is based on the GTFS Best Practices in Dataset Publishing & General Practices
At any time, the published GTFS dataset should be valid for at least the next 7 days, and ideally for as long as the operator is confident that the schedule will continue to be operated. If possible, the GTFS dataset should cover at least the next 30 days of service.
What do you think of having two different notices for those thresholds? It could open the door to defining different severity levels for each one with the profiles feature implementation (that will allow users to upgrade certain rules).
Also, there is a discussion in https://github.com/MobilityData/gtfs-validator/issues/886 on improving the way we measure the end date of a dataset. Currently, it's based on feed_info.feed_end_date, which is an optional field of an optional file.
I would agree that severity levels would be a good next step. There could have two notices but I don't think that would be very useful in practice.