I'd like to nominate the "stop_timezone" extension to stops.txt for formal
adoption in the GTFS specification.
This proposal has been previously discussed in a couple of places:
To restate the most recent version of the proposal:
Add the ability to specify which timezone a stop/station is in, in
order to facilitate the specification of intercity service.
For intercity services which cross timezone boundaries, it's necessary
to determine which timezone the start and end stops are in so that a
client can display the appropriate local time at each point. While
it's theoretically possible to determine a timezone from a
latitude/longitude geocode, it's non-trivial. Attaching a timezone to
stops and stations makes it easier for a GTFS-consuming application to
determine the correct offset while allowing stop times to still be
specified relative to a single time zone.
The following field would be added to the stops.txt file:
The stop_timezone field contains the timezone in which this stop or
station is located. Please refer to
a list of valid
values. If omitted, the stop should be assumed to be located in the
timezone specified by agency_timezone in agency.txt.
When a stop has a parent station, the stop is considered to be in the
time zone specified by the parent station's stop_timezone value. If
the parent has no stop_timezone value, the stops that belong to that
station are assumed to be the time zone specified by agency_timezone,
even if the stops have their own stop_timezone values. In other
words, if a given stop has a parent_station value, any stop_timezone
value specified for that stop must be ignored.
Even if stop_timezone values are provided in stops.txt, the times in
stop_times.txt should continue to be specified as time since midnight
in the time zone specified by agency_timezone in agency.txt. This
ensures that the time values in a trip always increase over the course
of a trip, regardless of which time zones the trip crosses.
*Adoption and Testing:*
A number of agencies are using this feature. An example of an agency using
this feature with a public feed is the chemultthruway-or-us feed hosted at
An example of a consumer of GTFS data using this feature is Google Maps.
Let's consider the same chemultthruway-or-us feed as an example. Look
at the Ontario, OR Greyhound Bus station schedule listed at:
Even though the stop_times.txt entry for this stop shows a scheduled time
of 9:10 am in the America/Los_Angeles timezone, the Ontario stops.txt entry
specifies America/Denver as its timezone, so the timetable properly lists
I'd like to start the clock for formal adoption of this proposal in one
week. If there are no major objections to the proposal or we have
consensus that proposal is reasonable, we can add the proposal at that
time. Otherwise, we can continue the discussion and figure out what's
needed to get this formally adopted.
I appreciate your feedback.