ISO-8601 date time for GTFS API itinerary responses

[leonardehrenfried]

Summary

This PR adds ISO-8601 formatted time responses to the GTFS GraphQL API.

I would like to speak about a few names in the dev meeting before, for example what is the realtime equivalent of the a "scheduled time"? I've called it "actual time" but there are a few other candidates:

• realtime
• predicted
• ???

Unit tests

Added.

Documentation

I would like to have a first round of review before I work more on the documenation.

[codecov]

Codecov Report

Attention: Patch coverage is 73.68421% with 40 lines in your changes are missing coverage. Please review.

Project coverage is 67.77%. Comparing base (41ffc95) to head (2f763e9).
Report is 35 commits behind head on dev-2.x.

Files	Patch %	Lines
.../org/opentripplanner/apis/gtfs/GraphQLScalars.java	44.44%	12 Missing and 3 partials ⚠️
...ntripplanner/apis/gtfs/datafetchers/PlaceImpl.java	61.11%	14 Missing ⚠️
...r/ext/fares/impl/CombinedInterlinedTransitLeg.java	0.00%	2 Missing ⚠️
...g/opentripplanner/ext/flex/FlexibleTransitLeg.java	0.00%	2 Missing ⚠️
...pentripplanner/model/plan/FrequencyTransitLeg.java	0.00%	2 Missing ⚠️
...va/org/opentripplanner/model/plan/StopArrival.java	0.00%	2 Missing ⚠️
...ntripplanner/model/plan/UnknownTransitPathLeg.java	0.00%	2 Missing ⚠️
...ipplanner/framework/time/OffsetDateTimeParser.java	94.11%	1 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #5660      +/-   ##
=============================================
+ Coverage      67.73%   67.77%   +0.04%     
- Complexity     16424    16505      +81     
=============================================
  Files           1898     1904       +6     
  Lines          72031    72213     +182     
  Branches        7419     7435      +16     
=============================================
+ Hits           48788    48941     +153     
- Misses         20729    20758      +29     
  Partials        2514     2514              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[leonardehrenfried]

ComplexTime ?
Call ?

[optionsome]

Is there some potential feature of a leg time that differs from a "stop time"? Also, does it make sense to always return this type which includes realtime related information even when it's not really feasible that there is any. For example if you walk from origin to a bike rental station? Maybe we should return an union of "realtime times" and "non-realtime times". Are there any other potential use cases for realtime times other than transit? Maybe we should call the realtime version "TransitTime" or "ComplexTime" and the other "SimpleTime"? For some reason, nothing feels perfect. Also, using a union/interface makes the client maybe slightly more complicated.

[leonardehrenfried]

I think the best solution would be to make Leg an interface and the implementations define what kind of time it provides.

But we all know that we can only do that with a new schema.

I will be doing some thinking if a union is better or not.

[optionsome]

Btw I stumpled upon https://github.com/graphql-java/graphql-java-extended-scalars?tab=readme-ov-file#how-to-add-extended-scalars-to-your-schema while researching how to utilize the extended scalars for the new plan query. Maybe we should use the @specifiedBy also.

[leonardehrenfried]

I will wait to merge this until we released 2.5.0.