On Mon, Jan 30, 2012 at 9:42 AM, Brian Ferris <bdfer
...@google.com> wrote:
> Just pinging the list on this proposal one last time. I will officially
> add this proposed extension to the spec tomorrow unless I hear any
> complaints. Speak now or forever hold your peace.
> Thanks,
> Brian
> On Mon, Jan 23, 2012 at 3:19 PM, Brian Ferris <bdfer...@google.com> wrote:
>> 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:
>> https://groups.google.com/group/gtfs-changes/browse_thread/thread/2bb...
>> https://groups.google.com/group/gtfs-changes/browse_thread/thread/708...
>> https://groups.google.com/group/gtfs-changes/browse_thread/thread/2dd...
>> To restate the most recent version of the proposal:
>> *Summary:*
>> Add the ability to specify which timezone a stop/station is in, in
>> order to facilitate the specification of intercity service.
>> *Motivation:*
>> 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.
>> *Proposal:*
>> The following field would be added to the stops.txt file:
>> stop_timezone (optional):
>> The stop_timezone field contains the timezone in which this stop or
>> station is located. Please refer to
>> http://en.wikipedia.org/wiki/List_of_tz_zones<http://www.google.com/url?sa=D&q=http://en.wikipedia.org/wiki/List_of...> for
>> 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 oregon-gtfs.com:
>> http://oregon-gtfs.com/gtfs_data/chemultthruway-or-us/
>> 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:
>> http://maps.google.com/maps/place?q=type:transit_station:%22Ontario+a...
>> 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
>> 10:10am.
>> *Next Steps:*
>> *
>> *
>> 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.
>> Thanks,
>> Brian
