stop_times.txt: Interpretation of times during daylight savings time transition

In GTFS, specifying trip schedules during the transition into and out of daylight savings time is complex.

## Background

Given the definition of time provided in the specification,

> 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 in HH:MM:SS local time for the day on which the trip schedule begins.
> Example: 14:30:00 for 2:30PM or 25:35:00 for 1:35AM on the next day.

Applying this rule to the date DST begins (March 13, 2022 in my region) and the date it ends (Nov 6, 2022), we obtain the following chart:

### Table 1

| DST Begins | | DST Ends | |
|----------------|------------------------------|---------------|------------------------------|
| **GTFS time** | **Date represented** | **GTFS time** | **Date represented** |
| N/A | N/A | -01:00 | Sun Nov 6 00:00:00 PDT 2022 |
| 00:00 | Sat Mar 12 23:00:00 PST 2022 | 00:00 | Sun Nov 6 01:00:00 PDT 2022 |
| 01:00 | Sun Mar 13 00:00:00 PST 2022 | 01:00 | Sun Nov 6 01:00:00 PST 2022 |
| 02:00 | Sun Mar 13 01:00:00 PST 2022 | 02:00 | Sun Nov 6 02:00:00 PST 2022 |
| 03:00 | Sun Mar 13 03:00:00 PDT 2022 | 03:00 | Sun Nov 6 03:00:00 PST 2022 |
| 04:00 | Sun Mar 13 04:00:00 PDT 2022 | 04:00 | Sun Nov 6 04:00:00 PST 2022 |
| 05:00 | Sun Mar 13 05:00:00 PDT 2022 | 05:00 | Sun Nov 6 05:00:00 PST 2022 |
| 06:00 | Sun Mar 13 06:00:00 PDT 2022 | 06:00 | Sun Nov 6 06:00:00 PST 2022 |
| 07:00 | Sun Mar 13 07:00:00 PDT 2022 | 07:00 | Sun Nov 6 07:00:00 PST 2022 |
| 08:00 | Sun Mar 13 08:00:00 PDT 2022 | 08:00 | Sun Nov 6 08:00:00 PST 2022 |
| 09:00 | Sun Mar 13 09:00:00 PDT 2022 | 09:00 | Sun Nov 6 09:00:00 PST 2022 |
| 10:00 | Sun Mar 13 10:00:00 PDT 2022 | 10:00 | Sun Nov 6 10:00:00 PST 2022 |
| 11:00 | Sun Mar 13 11:00:00 PDT 2022 | 11:00 | Sun Nov 6 11:00:00 PST 2022 |
| 12:00 | Sun Mar 13 12:00:00 PDT 2022 | 12:00 | Sun Nov 6 12:00:00 PST 2022 |

This has some unusual implications, which I am not certain are understood in the same way by all data producers and consumers.

* It is impossible to express the time "Nov 6 00:00" as part of the Nov 6 service day, unless negative hours are used. The specification never clearly defines or prohibits this practice.

* Consider a shuttle that runs once an hour on :15 past the hour, every day of the week. One could use this very simple schedule for the entire year:

| Time |
|-------|
| 00:15 |
| 01:15 |
| ... |
| 22:15 |
| 23:15 |

But this would actually create two duplicative trips on "Mar 12 23:15". When DST ends, it would skip the "Nov 6 00:15" run. Unfortunately, I've rarely encountered producers creating special services for the DST transition days.

## Questions

* Producers: How do you model your data during the those special hours when the DST transition is occurring? Aside from GTFS, how are service changes during those times communicated to riders?
* Consumers: Have you run into issues with DST while processing data, and do you use any workarounds internally?

## Potential changes

To reduce confusion, the specification could state that all trips during the DST transition (e.g. `00:00-03:00 Mar 13` this year in my timezone) shall be ignored. Producers would be required to use times between `24:00-27:00 Mar 12` instead. However, this is just a starting point for discussion and I hope that we can collaborate to find a good solution to this problem as a community.