bugfix: remove *1000 calculations to reintroduce accurate years in alerts in TORA

[lightsage88]

This pull request addresses an issue on TORA for Trimet. The issue is such that within the Alerts Body our years for the dates for which alerts have been effective since suddenly increased to wild numbers. In the attached image, you'll see that the years are hundreds of centuries in the future.

This commit includes a tweak that removes the *1000 calculation to the effectiveTime variable in the Alerts-Body file within the ItineraryBody package.

[miles-grant-ibigroup]

We can't merge this as is, as this would break OTP2 support

[lightsage88]

Oh okay, pursuant to the discussion on Slack, is there some way I can inspect within the console whether OTP 1 or 2 is running?

[miles-grant-ibigroup]

Your OTP server hosts a /otp endpoint which reveals all. It'll look something like this

[lightsage88]

Oh, so if major is one remove the *1000, otherwise leave it alone?

Is that about the gist of it or am I being too elementary about this?

[miles-grant-ibigroup]

That sounds right to me! The problem is I don't see how this package can easily determine the otp version. I will think on it

[lightsage88]

Hmm...well maybe we can pass a variable down from the TORA side that says what OTP we are using and then that attribute can filter down into Alerts Body and dynamically set whether or not we do the *1000 calculation or not.

[miles-grant-ibigroup]

I'm not a fan of that at all... I think there might be a way to detect OTP1 vs OTP2 based on the itinerary structure.

[lightsage88]

I'm not sure how to access the /otp endpoint you speak of...