Note: An Issue has been opened in the Google Transit repo to clarify the meaning of stop_timezone & agency_timezone.
Time - Time in the
HH:MM:SSformat (H:MM:SSis also accepted). The time is measured from "noon minus 12h" of the service day (effectively midnight except for days on which daylight savings time changes occur). For times occurring after midnight, enter the time as a value greater than 24:00:00 inHH:MM:SSlocal time for the day on which the trip schedule begins. Example:14:30:00for 2:30PM or25:35:00for 1:35AM on the next day.
Fun fact: if your transit system has a bus starting at 00:30:00 local wall time, then the only proper way I know to encode such bus in GTFS (static) is by defining it as
24:30:00of the previous day. It is otherwise impossible to encode this bus on a day when time is moved back by 1 hour (that is, the calendar day, when 13 hours pass between 00:00 wall time and 12:00 wall time) -- GTFS definition of time is 12 hours before local noon, which corresponds to 1am wall time for that day, and you'd need negative time to encode such a trip at such a day; GTFS00:30:00means wall time 01:30:00 on such day (assuming a typical switch-over time between 2am and 4am). In the same way on the short day (moving time forward), GTFS00:30:00will correspond to 23:30:00 wall time of the previous day.If I were to give a recommendation, I'd recommend to always provide times in GTFS (static) feeds in the time window of
03:00:00-27:00:00(or02:00:00-26:00:00, depending on when the typical DST-switchover happens in the system), because these times correspond to wall times on every day of the year.
As long as the DST <-> standard time switches happen before noon in every involved locale & timezone, GTFS Time values are monotonically increasing.
2019-10-27 with CEST
- switch from Daylight Saving Time (DST) to standard time
- "12 hours before noon": 01:00 (wall clock time)
| ISO 8601 | UNIX epoch | wall clock time | GTFS value |
|---|---|---|---|
2019-10-27T01:00:00+02:00 |
1572130800 |
01:00:00 | 00:00:00 |
2019-10-27T01:59:59+02:00 |
1572134399 |
01:59:59 | 00:59:59 |
2019-10-27T02:59:59+02:00 |
1572137999 |
02:59:59 | 01:59:59 |
2019-10-27T02:00:00+01:00 |
1572138000 |
02:00:00 | 02:00:00 |
2019-10-27T02:59:59+01:00 |
1572141599 |
02:59:59 | 02:59:59 |
2019-10-27T03:00:00+01:00 |
1572141600 |
03:00:00 | 03:00:00 |
2019-03-31 with CEST
- switch from standard time to Daylight Saving Time (DST)
- "12 hours before noon": 23:00 (wall clock time) of the previous day
| ISO 8601 | UNIX epoch | wall clock time | GTFS value |
|---|---|---|---|
2019-03-31T01:00:00+01:00 |
1553990400 |
01:00:00 | 02:00:00 |
2019-03-31T01:59:59+01:00 |
1553993999 |
01:59:59 | 02:59:59 |
2019-03-31T03:00:00+02:00 |
1553994000 |
03:00:00 | 03:00:00 |
Do you know if GTFS time values can be negative, i.e.
-00:05:00? The documentation explicitly states that values larger than24:00:00are possible, but there's no explicit min value.Even if no GTFS schedule would ever use a negative time, I think those could occur when working with delays.
For example, a vehicle might be scheduled for departure at
00:02:00and if this vehicle is found to have a delay of -5 minutes / -300 seconds, the actual departure could be-00:03:00. If this was not allowed, conversion to23:57:00(or one hour later/earlier when daylight saving switches) would be needed, as well as changing the date one day back. The latter seems to be problematic as well, given that a tuple oftrip_id,trip_start_dateand ideallytrip_start_timeis often used to identify a specific instance of a trip.