potentially wrong handling of GTFS Time values

[derhuerst]

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 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, but it seems that timetable_kit is affected by this problem on those days that the DST <-> standard time switch occurs on. I assume that wrong departure times will be generated.

I tried to find some places in the code base:

• https://github.com/neroden/timetable_kit/blob/f55f712794475eca779229e3782f7d2d6269256d/timetable_kit/timetable.py#L925-L941
• https://github.com/neroden/timetable_kit/blob/f55f712794475eca779229e3782f7d2d6269256d/timetable_kit/text_presentation.py#L296-L319

---

related: https://gist.github.com/derhuerst/574edc94981a21ef0ce90713f1cff7f6 related: https://github.com/google/transit/pull/15

[neroden]

A few points:

1 - For timetables which cross more than one time zone, the code currently only handles North American time zones anyway. No other time zones can be printed on the output timetable. The code is not currently generalized enough to do any better than that. (It would be good to generalize that.) It should work for timetables in other places which are all within one time zone, though.

2 - The intended purpose is to make "standard" or "reference" timetables for "typical" days.

Weirdness such as what happens when you change from daylight savings to non-daylight savings time in the middle of a day is simply not handled at all. Don't use that day as a reference date for generating the timetable.

In fact, we don't handle the calendar_dates.txt file at ALL, so we won't catch any one-off special timetables of any sort. (I want to handle that at some point, but it's not a priority.)

You shouldn't be generating a timetable for such a day using timetable_kit at this time.

I'm closing this as beyond the specifications of the project -- unless someone has a real reason for producing a printable timetable specifically for the day when you transition in and out of daylight savings time. If you are actually doing that, we can reopen this.

[derhuerst]

Don't use that day as a reference date for generating the timetable.

Fair enough! 🙂

I think this should be documented as a limitation in the readme, given that, as a person that doesn't know (or think about) the intricacies of DST & bus schedules, it will lead to unexpected outcomes.

Weirdness such as what happens when you change from daylight savings to non-daylight savings time in the middle of a day is simply not handled at all.

Note that this is not (just) about a shift in the middle of the day, but all cases whenever any trip runs across a DST shift.