feat: Include service window in Summary report

[emmambd]

Describe the problem

Currently, the summary section of the validation report shares the feed_start_date and feed_end_date when it's provided. However, many feeds don't include feed_info.txt, which makes it difficult to know the service window at a glance.

Proposed solution

• Add full service date range to summary report. Calculation here

• Pseudologic for the date range here:

• When only calendars.txt is used: Loop through all services referenced with a trip_id in trips.txt. Loop through all those services with a trip_id incalendars.txt. check that there have an start_date and end_date - take the earliest start date and the latest end date
  When only calendar_dates.txt is used: Loop through all services referenced with a trip_id in trips.txt. Loop through all those services in calendar_dates.txt. Take the earliest date and the latest date
  When both are used: Loop through all services referenced with a trip_id in trips.txt. Calculate the earliest start date and the latest end date for each service with a trip_id using calendars.txt , and then check to make sure there isn't a service exception in calendar_dates.txt on either of those dates

Design considerations

• The summary report is getting busy (example here). How do we make sure this info fits and is intuitive?

Alternatives you've considered

No response

Additional context

• Include both feed date range and service range
• In the future, calculate based on majority of dates
• Look at other validators' approach to calendar dates, e.g Google Partner Dashboard
  No response

[qcdyx]

Hello @emmambd I started evaluating this issue, could you add more use cases like when calendar.txt and calendar_dates.txt coexists, which one is preferred?

[emmambd]

In terms of how to display this in the validator, as a simple starting point I'd suggest:

Under Feed Info:
• Service date range
• Majority service window range with a tool tip to clarify what this is. E.g. "The date range when a significant number of trips are running. This helps detect when a single trip makes a feed appear "active" even though the bulk of service is no longer running."

[Alessandro100]

Focus on the Service date range. Majority service window later

Split ticket

1. Service date range
2. Majority service window
3. Add service date range to API
4. service date range 'expired' state

Tasks
[] Calculate the service date range
[] Unit test
[] Add service date range for UI and JSON report
[] Acceptance test review

[qcdyx]

For Clarification: Do we use the word "to" to connect the start date and end date or some other characters? @emmambd

[emmambd]

@qcdyx That works!

I'd be curious if the service date range always matches what it's feed_info.txt when it's present...things to play with in QA!

[qcdyx]

@emmambd Clarifying questions:

What if earlistStartDate is null and latestEndDate is not null? Do we display "Service Date Range: N/A" or just the not null Date?

[emmambd]

@qcdyx Can you share the feed as an example? This would mean there's only 1 service date in use for the whole feed, right?

In this case, we should just include the 1 day with no dashes.

[qcdyx]

@emmambd I don't have a specific example. I'm just wondering if I should add that logic.

[emmambd]

@qcdyx Got it - it shouldn't happen but it is a possible edge case. Example would be:

Service Date Range: January 2, 2025