potentially wrong handling of GTFS Time values

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 very inexperienced with Java and not familiar with this code base, but it seems that TheTransitClock is affected by this problem on those days that the DST <-> standard time switch occurs on.

I'm not sure how that actually manifests in TheTransitClock's output, but I assume that wrong delays will be calculated, or that realtime data can't be matched against static data.

I tried to identify all affected places in the code base:

Technically also these are wrong, because they convert a GTFS Time into a human-readable time string:

https://github.com/TheTransitClock/transitime/blob/5347c073752a3c9d66d7837f77ad6b9359a9d9c9/transitclock/src/main/java/org/transitclock/utils/Time.java#L598-L632

Version:

Just poked around in the develop source code.

TheTransitClock / transitime

potentially wrong handling of GTFS Time values #228