Association stop has departure time shifted by +1 day incorrectly

[planarnetwork]

Association stop has departure time shifted by +1 day incorrectly

[linusnorton]

I don't have an association between P76348 and P75734 in my data. But it was a deliberate choice to mix the times from the base/assoc schedules.

For a split:

Arrival time at assoc location comes from the base and departure time from the assoc AS the assoc does not have an arrival time at the assoc location (it's always the first stop). The departure time comes from the assoc schedule as it has deviated from the base schedule at that point.

For joins:

The arrival time at the assoc location comes from the assoc schedule and the departure comes from the base. Some logic more or less as the split but inverted.

I will keep this open but let me know if it can be closed off.

[linusnorton]

This bug may have been corrected by fixing #3 as it may have detected a backwards step in time and tried to move it forward to compensate. I'm trying to find another example to verify

[mk-fg]

I'll check same CIF data with the updated code, see if it goes away for this particular case.

[mk-fg]

Looking at 52f6752 (fix for #3), I think it shouldn't affect this particular issue.

More specific problems highlighted by it:

• If A has association with B, and association stop is "pickup only" or "dropoff only", then there is a "scheduled time mixed in with public time" situation again, which - as demonstrated in #3, seem to occasionally produce such mismatches, and probably shouldn't result in "+1 day" scenario.

• Potentially there can be entirely new mismatch in "public arrival for A vs public departure time for B", unrelated to mixing scheduled/public times, will check if it's the case here.

• If association stop legitimately has departure time moved to the next day, code doesn't seem to move all the stops after it, which seem to be a bug.

[mk-fg]

If association stop legitimately has departure time moved to the next day, code doesn't seem to move all the stops after it, which seem to be a bug.

There seem to be separate logic for midnight rollover in Association.ts, which I have in Schedule constructor in py code, wonder if maybe it'll fit code style here to have it there as well, hence making it impossible to create Schedule without rollover applied in uniform manner.

Also, it's kinda easy to make heuristic to detect that "19:12 -> 19:11" is probably not a midnight rollover, e.g. check if "time1>23:00 and time2<1:00", or "time2-time1 <<< time1-time2" (i.e. "1m <<< 23h59m" in this case) and such.
Can potentially get rid of all such small quirks, though didn't do proper check yet for how many of them are in the data.

EDIT:
For reference, in py code I have first kind of two checks described above:
https://github.com/mk-fg/open-track-dtd2mysql-gtfs/blob/f5017c8/mysql-dtd-to-gtfs.py#L386-L407

[mk-fg]

I'll check same CIF data with the updated code, see if it goes away for this particular case.

Still definitely have the issue with fix from #3.

As I'll be experimenting with newer data soon, will see if such cases still appear there.
Can also send you this old cif.sql export (though you might still have it too), but you can probably reproduce it easily in tests for problematic cases described above, if they seem relevant enough to address.

[linusnorton]

Send it over and I will try it out

[linusnorton]

@mk-fg don't worry I found it

[linusnorton]

Okay, another one with tricky data. In this instance the associated schedule arrives at the association location after the base schedule departs that same location. Obviously a bit of a nonsense but I'll have to find a way to deal with it.

[linusnorton]

I've just pushed a change so that it only increments if the next day flag is set. Not bullet proof but should do the trick.