You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As explained in my note about GTFS Time values, with the Europe/Berlin time zone (+1h standard time to +2 DST shift occurs at 2021-03-28T02:00+01:00), I expect
the departure_time of 00:30 of a trip running on 2021-03-28 to happen at 1616884200/2021-03-28T00:30+02:00, not at 1616887800/2021-03-28T00:30+01:00;
the departure_time of 06:30 of a trip running on 2021-03-28 to happen at 1616905800/2021-03-28T06:30+02:00, not at 1616909400/2021-03-28T06:30+01:00.
Describe the bug
I'm not familiar with this code base (just a random stranger dropping by to poke around 🙈), but it seems that combine_gtfs_feeds is affected by this problem on those days that the DST <-> standard time switch occurs on.
I'm not entirely sure how that actually manifests in combine_gtfs_feeds' output, but I assume that wrong headway-based stop_times will be calculated.
This library does not make any changes to the schedule that is published in the input GTFS feeds. In other words, the output stop_times.txt reflects what is in the input GTFS feeds in the output, for the trips that are kept.
GTFS Time is not defined relative to midnight, but relative to noon - 12h. While that makes "writing" GTFS feeds easier, it makes processing a lot harder.
Expected functionality
As explained in my note about GTFS Time values, with the
Europe/Berlin
time zone (+1h standard time to +2 DST shift occurs at2021-03-28T02:00+01:00
), I expectdeparture_time
of00:30
of a trip running on2021-03-28
to happen at1616884200
/2021-03-28T00:30+02:00
, not at1616887800
/2021-03-28T00:30+01:00
;departure_time
of06:30
of a trip running on2021-03-28
to happen at1616905800
/2021-03-28T06:30+02:00
, not at1616909400
/2021-03-28T06:30+01:00
.Describe the bug
I'm not familiar with this code base (just a random stranger dropping by to poke around 🙈), but it seems that combine_gtfs_feeds is affected by this problem on those days that the DST <-> standard time switch occurs on.
I'm not entirely sure how that actually manifests in combine_gtfs_feeds' output, but I assume that wrong headway-based stop_times will be calculated.
I tried to find some places in the code base:
combine_gtfs_feeds/combine_gtfs_feeds/cli/run.py
Lines 106 to 112 in cb78603
combine_gtfs_feeds/combine_gtfs_feeds/cli/run.py
Lines 150 to 168 in cb78603
related: google/transit#15
The text was updated successfully, but these errors were encountered: