April OTP-UI package updates

[amy-corson-ibigroup]

Description:
Core utils: https://github.com/opentripplanner/otp-ui/releases/tag/%40opentripplanner%2Fcore-utils-v12.2.0
Geocoder: https://github.com/opentripplanner/otp-ui/releases/tag/%40opentripplanner%2Fgeocoder-v3.0.4
Itinerary body: https://github.com/opentripplanner/otp-ui/releases/tag/%40opentripplanner%2Fitinerary-body-v6.2.0

Also added ensureAtLeastOneMinute to itinerary durations

PR Checklist:

• Does the code follow accessibility standards (WCAG 2.1 AA Compliant)?
• Are all languages supported (Internationalization/Localization)?
• Are appropriate Typescript types implemented?

[miles-grant-ibigroup]

Was there really no way to do the rounding work within react-intl?

[miles-grant-ibigroup]

This is like taking a deep breath next to an exhaust pipe

[miles-grant-ibigroup]

could we add a comment that explains that we need it to be exactly 0 in some cases, but any value between 1 - 59 is problematic!

[binh-dam-ibigroup]

Should that condition also appear on lines 240 and 394, and 486?

[amy-corson-ibigroup]

Added in c664f9b

[amy-corson-ibigroup]

We didn't look at react-intl. We can go back and explore options with roundingIncrement if you want but since these versions have already been released and they work I'd at least like to use them as a stop gap.

[binh-dam-ibigroup]

Was there really no way to do the rounding work within react-intl?

react-intl does not (should not) handle calculations.

[binh-dam-ibigroup]

Should the non-zero duration check be used in more places?

[binh-dam-ibigroup]

Should this condition also appear on line 95?

[amy-corson-ibigroup]

My thinking was it would be nearly impossible to have a leg/itinerary with an exact duration of 0 so it felt like an unnecessary check. However for itineraries that might not have any walk legs, we don't want to accidentally add a default walk time of 1min to an itinerary with absolutely no walking.

Although maybe when you're taking transit it's equally as unlikely to have itineraries with 0 walking, so we should just apply the check across the board to be safe?

[miles-grant-ibigroup]

Leg with duration 0 is very common! That's how we identify transfer legs

[miles-grant-ibigroup]

I think I'd prefer applying the check inside core-utils. Are we ok to block this PR?

[amy-corson-ibigroup]

First of all, it's not how we identify transfer legs, we identify them by checking if leg.to.stopId === leg.from.stopId
Second of all, we don't show the leg duration on transfer legs:

So I don't understand why this would be a reason to block the PR

[miles-grant-ibigroup]

Sorry I wasn't clear. The reason to block is to avoid having to check for explicitly 0 leg durations in multiple places

[amy-corson-ibigroup]

I do not think we should have to check for explicitly 0 leg durations in multiple places. It makes sense to have this check here, because we could feasibly get an itinerary with a 0 walkDuration and we would not want to replace that with a 1min. For example, you plan a trip that starts at one bus stop and ends at another bus stop.

Are there examples where we would need to show a 0min duration for a leg in the itinerary? A leg is going to take you from point A to point B and that's going to take time. The point of the util is to avoid implying that it's going to take 0 time.

[amy-corson-ibigroup]

And just to be clear so I'm not contradicting myself, I know I said

so we should just apply the check across the board to be safe?

But thinking about it further, I don't think there's a reason to.

[binh-dam-ibigroup]

Should that condition also appear on lines 240 and 394, and 486?

[binh-dam-ibigroup]

I am good with the explanation ton only roundup non-zero walk leg durations.

[miles-grant-ibigroup]

Since the 0 check is only happening in one place I'm happy to merge

[amy-corson-ibigroup]

Thanks everyone!