@barbeau I think there are 2 commits because I didn't branch correctly locally. Sorry about that. This PR regards only changes in a306d2d

Invalid field value should be Invalid time field value to differentiate it from other type rules - same for other type rules.

Errors are differentiated in the errorDescription field with the title always being the same (title = generic, description = specific). Do you think title should also be made specific ?

I think this allows for HHH:MM:SS? The GTFS spec only specifies HH:MM:SS, so I'd limit to this:
https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#field-types

Added to the test suite, seems to correctly reject HHH:MM:SS as is

I would suggest a separate warning for flagging suspicious times. For example, very rarely will 99:59:59 actually be a valid value in stop_times.txt - it would need to be a four day trip. We can't flag these as errors as they could be correct in outlier cases, but we should flag as warnings so bad times more visible.

Yep, I thought as well. Could you guide me as what would be a sensible cutoff value to make the distinction ? something like over 26:59:59 being suspicious ?

Errors are differentiated in the errorDescription field with the title always being the same (title = generic, description = specific). Do you think title should also be made specific ?

Yes, I'd make the title specific too. It makes it much easier to understand what the rule is when scanning a table like https://github.com/CUTR-at-USF/gtfs-realtime-validator/blob/master/RULES.md#table-of-errors.

Yep, I thought as well. Could you guide me as what would be a sensible cutoff value to make the distinction ? something like over 26:59:59 being suspicious ?

Choosing the threshold is the hard part :). When possible we tried to base the thresholds in GTFS-rt validator on real data. So the scientific way to do this would be to run a query against https://openmobilitydata.org/ and find the 95th percentile of times, and use this. You could ask Leo if it's ok to reach out to Matt at TransitScreen to ask if they could run this type of query (Drew at Interline for TransitLand would be the other option). Outside of this, though, you could post a question to GitHub google/transit, or the transit-developers group. My personal guess is that 26:59:59 seems reasonable. The problem with asking, though, is that everyone will have their own opinions and then you have to pick one, invalidating everyone else's :).

For any such thresholds, I would also suggest that we consider making them user-configurable via command-line parameters.

Yep, I thought as well. Could you guide me as what would be a sensible cutoff value to make the distinction ? something like over 26:59:59 being suspicious ?

Choosing the threshold is the hard part :). When possible we tried to base the thresholds in GTFS-rt validator on real data. So the scientific way to do this would be to run a query against https://openmobilitydata.org/ and find the 95th percentile of times, and use this. You could ask Leo if it's ok to reach out to Matt at TransitScreen to ask if they could run this type of query (Drew at Interline for TransitLand would be the other option). Outside of this, though, you could post a question to GitHub google/transit, or the transit-developers group. My personal guess is that 26:59:59 seems reasonable. The problem with asking, though, is that everyone will have their own opinions and then you have to pick one, invalidating everyone else's :).

For any such thresholds, I would also suggest that we consider making them user-configurable via command-line parameters.

hey @LeoFrachet , what do you think would be a sensible approach to defining the threshold value ?

Merging this with a '27:00:00' warning threshold while opening a feature issue to fine tune the value