When a GTFS day end

[Paul Harrington]

Hi,

The GTFS spec says

"For times occurring after midnight on the service day, enter the time as a value greater than 24:00:00 in HH:MM:SS local time for the day on which the trip schedule begins. "

Is there any rules regarding when a service day ends ? Or do most agencies tend to end around the same time ?  In many case it may be straightforward, if for example the latest night arrival at a stop in an operators network is 1:15am and the earliest morning start is 5:15am then a concept of a day ending at 2am, 3am, 4am or 5am all work. But for services running every 30 minutes through the night for example, is there a consensus on when the new day starts ?

I currently use 3am but am wondering do any GTFS providers use arrival and departure times beyond 27:00 in their stop_times GTFS file ?

Thanks Paul.

[Andrew Byrd]

On Jan 24, 2018, at 17:25, Paul Harrington <harri...@gmail.com> wrote:

Is there any rules regarding when a service day ends ?

This system exists to accommodate different agencies that end the service day at different times. A properly implemented GTFS consumer should be able to handle time ranges like 00:00-24:00, 01:00-25:00, 02:00-26:00 or even 00:00-27:00. This allows agencies to use their own “natural” service day.

I currently use 3am but am wondering do any GTFS providers use arrival and departure times beyond 27:00 in their stop_times GTFS file ?

I haven’t analyzed existing feeds to look for patterns in when overnight service breaks happen, but as someone who has worked on several open source GTFS consuming apps I can say we’ve always considered the fact that some trains run for several days, and would at least accept and attempt to properly handle times up to 48:00. 

Regards,

Andrew

[Devin Braun]

In general, for services running 24 hours every x minutes, it probably doesn’t matter except during days when service levels change or schedules change.

 

The point of days starting and ending is so that you know how to interpret when a trip runs based on the calendar date that the trip is assigned to.  I’ve heard of some train trips which can span three or more days. 

--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Harrington]

From what I'm reading here I guess it is a design flaw in my own implementation. I posted something similar 10 months ago and nobody else seemed to have difficulty with it.

The root of the problem I think is that when I load the schedule into the database I don't use timestamps. Departure times are inserted like 08:35:00 or 24:30:00 (I zero pad when adding) and calendar dates like 20180130.

When searching for next departures at a stop at a time between midnight and 3am I rolled back a day and added 24 hours to the hour so instead of running a query for departures at a stop starting from a  date of 20180124 and a time of 01:00:00 I would use 20180123 and 25:00:00

If the query starts from 3:30am however I would run the query starting from a date of 20180124 and a time of 03:30. This would however miss a trip with an arrival time at the stop of 28:00 if one exists. 

Obviously by tweaking the changeover time to match the operator these edge cases can be diminished, however it is not the cleanest way of doing things. 

For those querying based on timestamps, I presume you have effectively have a DB entry for each day in the schedule that a trip runs. I veered away from this approach in the beginning as I had no idea how long the period covered by the GTFS feed would be. I've rarely seen a large feed span more than 3 months so I could possible redesign to use timestamps in future.

[Brij Nanda]

Thanks Paul

Thats a good understanding of GTFS.