Daylight savings time

[David Turner]

Many (all?) data producers are not handling daylight savings time
correctly.

I just checked out the NY MTA plus six GTFS files recently posted to
gtfs-data-exchange.com which covered the period including March 14th
(the US spring forward day). Only one of them has a special schedule
for that day -- but probably only because it was a university shuttle
over Spring Break.

Recall that a special schedule is needed on DST switchover days, because
of the new definition of midnight. A trip that has a departure time of
08:00:00, will depart at 7 AM when the hour springs forward, because
midnight is 23:00.

I don't want to waste too much of gtfs-data-exchange's bandwidth
checking every feed on earth. Google, can you tell us if anyone at all
has an adjusted schedule for DST switchover days? If not, it would be
much easier to consider changing the spec, if the list wants to
resurrect the various auto-adjustment-mode proposals. Personally, I
think it's a pretty good idea, because not that many agencies have
service at the switchover time, meaning that an automatic mode would
lead to less GTFS management and fewer errors.

Google Transit either does not implement the GTFS definition of
midnight, or has an adjustment in place for the Long Island Railroad (a
random non-dst-adjustment-having agency that was easy for me to check)
and presumably other agencies. Since I know of no agencies that *do*
have correct schedules, I can't tell which of these is the case.

The agencies I checked out include some contributors to this list.
Since it is not immediately obvious that a special DST switchover
schedule is required, I don't blame agencies for missing it.

I put in a ticket for the feed validator to check this, but I'm not sure
that's sufficient to actually convince agencies that they need to do a
bunch of extra work.

[Brian Ferris]

I think we addressed this already in previous discussion:

http://groups.google.com/group/gtfs-changes/browse_thread/thread/cd1ac522472fc0e/72d9f8c1e8e6600a

The GTFS spec has been altered to state "The time is measured from "noon minus 12h" (effectively midnight, except for days on which daylight savings time changes occur) at the beginning of the service date."

This has the nice feature of making almost all existing GTFS feeds DST compatible.

The OneBusAway GTFS library, for example, has been modified to support this convention and in fact March 14th was the first DST day where I didn't have any unforeseen service issues with OneBusAway with regard to DST ; )

Brian

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To post to this group, send email to gtfs-c...@googlegroups.com.
To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.

[David Turner]

On Thu, 2010-03-18 at 16:08 -0700, Brian Ferris wrote:
> I think we addressed this already in previous discussion:
>
>
> http://groups.google.com/group/gtfs-changes/browse_thread/thread/cd1ac522472fc0e/72d9f8c1e8e6600a
>
>
> The GTFS spec has been altered to state "The time is measured from
> "noon minus 12h" (effectively midnight, except for days on which
> daylight savings time changes occur) at the beginning of the service
> date."

Perhaps I am misinterpreting this, then.

I think it means that a trip departing at 08:00:00 departs on March 14th
at wall-clock time 7 am, because the night is short, so noon minus 12
hours is 23:00:00 the previous day.

What do you think it means on the above data?

[Brian Ferris]

I would interpret a 8:00 stop time as arriving and departing 8 hours
from the start of the active service date. Service dates typically
start at midnight, but the start of the service date is calculated as
noon - 12 hours. Thus, the Mar 14th service date actually started at
23:00 on Mar 13th. However, add eight hours to that and you still get
8:00am on Mar 14th (assuming you are usind a TimeZone and DST-aware
calendar function, like java.util.Calendar etc). Does that make
sense?

Brian

[David Turner]

Oh, yeah, duh. I totally screwed that one up.

So the only thing that need to change on DST-changing days are trips
during the first hour (23:00 wall-clock time)

[Brian Ferris]

Yep. Though as someone pointed out in the previous thread, you can
avoid issues with those special trips that occur right before the DST
switch by scheduling them relative to the previus day's service date
(aka Saturday). Not that my local agency does this, but it's such a
small set of trips that I haven't compained.

[Jehiah Czebotar]

Brian++ for a clear example. I actually think an example like this
would be good to add to the specification.