RFC: The timezone of the feed

[Stefan de Konink]

agency.agency_timezone contains the timezone where the transit agency is
located. At this moment GTFS has a mandatory requirement that a single feed
consisting of multiple agencies must all share the same timezone. While
this is a good practice with respect to consistency and prevents ambiguity
in stop_times, it doesn't hold the requirement that the
agency.agency_timezone contains the timezone where the transit agency is
located. At presentation the timezone may be overridden using
stops.stop_timezone where it transforms the stoptimes into the local
timezone.

Any sane GTFS client implementation shouldn't care less where the agency is
located for routing purposes, because any timezone is supported. In that
line of reasoning one may ask why the standard is being so strict on that
single timezone? The stop_times.trip_id is hooked up via trips.route_id to
routes.agency_id and agency.timezone. It would not be an impossible
adventure to match up the correct timezone by agency, but for human
generation or consumention of the feed, without using any tools that join
tables, quite a hassle and error prone.

But what if not the agency is located in one timezone but operates trips in
multiple time zones? A practical example is Eurostar between London and
Paris, but any operator from France to Moscow would fall in the category.
The GTFS standard now states that the feed would be either GMT (Eurostar
office in London), CET (SNCF), or UTC+3 (Russian Railways).

Fundamentally speaking I think it would be a good idea to get stop_times in
UTC. Unambiguously. As bonus it would solve potential problems with
summer-winter time transitions early. To display the information a
transformation is done to agency.agency_timezone or when available to
stop.stop_timezone. This transition is not easy because it would break
existing implementations. Or wouldn't it? Any agency.agency_timezone can be
used, including UTC. But would require to include a stop.stop_timezone as
required element.

For complex feeds the requirement of specifying the exact transit agency
location as timezone is already lifted. I feel we must come up with a best
practice GTFS implementation guide where agency.agency_timezone = UTC and
stop.stop_timezone (required) becomes the new standard.

--
Stefan

[Eric Burkman]

Is this an actual, real-world problem? Or just a theoretical one?

I'm asking because there is a similar problem around seasonal time changes (Daylight Saving Time start/end) for agencies that operate late-night service. When I was working in bus operations we would start and end the service day in the same type of time (Daylight Time or Standard Time) in order to avoid all sorts of labor and accounting problems.

Maybe the agencies that span time zones simply pick one time zone and stick to it, in which case this isn't a problem with the feed specification - it's a problem with the consumer applications.

Is there someone out there from an agency that operates in multiple time zones? How does your agency navigate the issue? Or maybe you already know the answer to this, Stefan?

-Eric

[Stefan de Konink]

On dinsdag 28 februari 2017 14:47:42 CET, Eric Burkman wrote:
> Is this an actual, real-world problem? Or just a theoretical one?

Real world. I thought the examples were clear :)

> Maybe the agencies that span time zones simply pick one time
> zone and stick to it, in which case this isn't a problem with
> the feed specification - it's a problem with the consumer
> applications.
>
> Is there someone out there from an agency that operates in
> multiple time zones? How does your agency navigate the issue? Or
> maybe you already know the answer to this, Stefan?

My problem was there there was a consumer that claimed "THIS IS NOT
ACCORDING TO THE SPECS!!11!!" Hence I want the specs to be clear that UTC
is a very good practise in this case ;)

--
Stefan

[Eric Burkman]

Yes, the examples were very clear indeed. I was more asking what the actual agencies use currently (both as an operational practice and as a GTFS practice), but it seems from your clarification that they're using UTC in GTFS.

-Eric

[mikeness]

A related problem in the use of time zones, which may well be increased by the use of UTC, is whether days and dates of operation should be based on the local time at the start of the journey or based on the agency time zone at the start of the journey.

As an example a train leaves Paris at 00:30 local time on Monday 27 February.

Option 1. If agency time zone of Europe/London (ie UTC) is used calendar.txt should show this as operaring on Sunday 26 February and stop_times.txt will show it as leaving at 23:30:00.

Option 2. If agency time zone of Europe/London (ie UTC) is used calendar.txt could show it as operating on Monday 27 February and stop_times.txt would have to show it as leaving at -(00:30:00)

Option 3 .If agency time zone of Europe/Paris is used calendar.txt will show this as operating on Monday 27 February and stop_times.txt will show it as leaving at 00:30:00

With standardising on UTC the GTFS spec rules out negative times so option 2 fails and one is left with having to adjust both the days and dates of operation (option 1) on data input to GTFS and when publishing information derived from GTFS. Option 3 does not require any adjustments.

Adjustment of days and dates of operation can be avoided by defining agency time zone to be the eastmost time zone covered by the timetable. This avoids creating negative times and only need adding time for further west time zones which is allowed for in GTFS as time may go beyond 24:00:00. eg A Eurostar service leaving London at 23:30 on Sunday 26 February would be coded with agency time zone of Europe/Paris, calendar.txt showing a Sunday service on 26 February and stop_times showing 24:30:00 departure. The London stop would have a stop_timezone of Europe/London.

I have not started to think how to code Trans Pacific journeys crossing the International Date Line in GTFS.

Mike

[Stefan de Konink]

On Wednesday, March 1, 2017 12:26:58 PM CET, mikeness wrote:
> A related problem in the use of time zones, which may well be
> increased by the use of UTC, is whether days and dates of
> operation should be based on the local time at the start of the
> journey or based on the agency time zone at the start of the
> journey.
>
> As an example a train leaves Paris at 00:30 local time on
> Monday 27 February.

A trip always leaves on the scheduled operating day. Which is Monday 27
February, but in train operation it is even common that any trip before 4
am is part of the previous operating day, where Sunday 26 February is valid
to in my opinion.

The timing in UTC therefore remains correct to adding 'seconds' to the
original departure and compensating for the timezone at the end of the
proces.

> Adjustment of days and dates of operation can be avoided by
> defining agency time zone to be the eastmost time zone covered
> by the timetable. This avoids creating negative times and only
> need adding time for further west time zones which is allowed
> for in GTFS as time may go beyond 24:00:00. eg A Eurostar
> service leaving London at 23:30 on Sunday 26 February would be
> coded with agency time zone of Europe/Paris, calendar.txt
> showing a Sunday service on 26 February and stop_times showing
> 24:30:00 departure. The London stop would have a stop_timezone
> of Europe/London.

The above gives a statement that it should - in this specific case - be the
London timezone. (not UTC) But is a workaround for a problem, not a
recommendation to solve the general case. What is the logic that Russian
Railways should be in CET/CEST because one of their trains departs from
Europe? CET/CEST is not a "standard".

> I have not started to think how to code Trans Pacific journeys
> crossing the International Date Line in GTFS.

UTC + Noons always works.

--
Stefan