Hi @nate_wessel,
The concept of periods of time for UrbanAccess is designed as a way to subset a transit network into a operational range to make things more manageable, ensures your graph network is fully traversable from one end of the region to another, and for the generation of average headways if that will be utilized. You are correct in your assumption that the "departure time" is approximately the start of that time period so 7am to 10am the start time is 7am. Pandana is the tool that does the heavy lifting in terms of the calculation of the shortest path so it is looking at all the travel times on the edges in that operational window to compute shortest path.
In terms of passenger wait times, that is correct these are estimated by computing the average headways for each route at each stop for your time period and adding that time to the one direction pedestrian to transit edge connector. In the demo pure travel times refers to the edge weights that are derived from only the travel times computed from the schedule. So no headways are utilized. If headways are not used there is no explicit passenger wait time information added to your edges and which technically means the transit vehicle is there as you arrive. However, the caveat is that if the transit agency has built in time into its scheduled departure time in the GTFS feed such as dwell times or timed transfers these components will be reflected in the pure travel times which can in some ways account for some fractions of passenger wait time even though it is not a full accounting of passenger wait times.
