TripDescriptor.start_date matching between GTFS-RT + GTFS-static about transit HOT 2 OPEN

(This is not Google's or MobilityData's position on this, merely my personal interpretation of the spec and the surrounding materials & discussions.)

Some fields in the specification are explicitly specified to be in UTC. For the rest I can assume that they refer to the GTFS-static local times?

Side note: As discussed very recently in #322, there is a different between agency_timezone and stop_timezone.

I would assume that all Time fields in GTFS that can be tied to an agency (e.g. stop_times.*, frequencies.*) are "relative to" the timezone specified in agency_timezone.

• What happens in case the first departure time is greater than 24:00:00? The start date is the one specified in the service_id or the "real" start date (which would be for example on the next day)?

I would expect a TripDescriptor.start_time to always refer to the service day of the scheduled trip "run" in the corresponding GTFS Schedule dataset.

Let's consider a specific example: If there is a scheduled trip t1 with a first departure of 26:00:01 that runs on service days 20230606 ("run" A, effectively starting at 2023-06-07T02:00:01) and 20230607 ("run" A, effectively starting at 2023-06-08T02:00:01), I would expect a GTFS-RT TripDescriptor

• with start_date=20230606 and start_time=26:00:01 to match "run" A;
• with start_date=20230607 and start_time=26:00:01 to match "run" B;
• with start_date=20230607 and start_time=02:00:01 not to match anything (and render the TripUpdate invalid).

If my assumptions are right, then technically the TripDestriptor.start_{date,time} merely describe a local (as in "wall clock time") date+time, as the timezone is only indirectly implied via the GTFS Schedule dataset's agency_timezone. Therefore, start_{date,time} are to be treated rather like a foreign key uniquely referencing a single "run" in the GTFS Schedule dataset.

from transit.

Thank you very much @derhuerst! I think it absolutely makes sense if you interpret start_date more like a database key (derived from service_id via calendar_dates.txt and calendar.txt entries, no matter if the first departure from stop_times.txt is greater or smaller than 24:00:00) and not like a real date identifying the day on which the trip has its first departure (in whatever timezone). It might make sense to add a clarification to the standard and leave the issue open until then?

from transit.