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:SS
format (H:MM:SS
is 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:SS
local time for the day on which the trip schedule begins. Example:14:30:00
for 2:30PM or25:35:00
for 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:00
of 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:00
means 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:00
will 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 |
What does the use case look like? When would you want to express delayed vehicles in GTFS Static? GTFS Realtime uses unix timestamps (as in seconds since the Unix epoch) to express absolute points in time, and therefore does not have the properties described in the Gist above.
I don't know, you'll have to clarify in the GTFS issue tracker.
Yes, I made that observation as well. Using these as an ID is problematic for various reasons.