Amtrak partners with Google

Amtrak Unlimited Discussion Forum

Help Support Amtrak Unlimited Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
The change from Daylight Saving to Standard Time takes place at 3 am (3 becomes 2). So the departure and arrival times for that train leaving New York at 12:20 am would be correct; the train would arrive in Philly before the time change. But the computer seems to be subtracting an hour from the running time even before the time change, giving the trip time of 25 min. And for only $10. I know what I'll be doing on Nov. 3: riding Amtrak from New York to Philly and looking at SpeedView on my phone. ;-)
 
GTFS Fare is under development. Current V2 does not support dynamic fares and is not suitable for Amtrak. It is currently designed for representing transit fares and is used by several agencies.

In any case as you correctly point out, for dynamic fare like used by Amtrak the only truly useful fare is the one provided in a specific offer from the CRS as I indirectly alluded to earlier. All that can be provided statically is a range info and that currently cannot be represented in the GTFS Fare documents.

Correct, as someone who maintains GTFS fares professionally for two transit agencies GTFS only has the ability to display a single fare for a trip (their is a way to program different fare zones, between different areas or stations), so if Amtrak wanted to i guess they could program the highest bucket fare for each segment but I think that would turn passengers away by seeing sky high prices.
 
IMHO, the issue is that the bones of Amtrak's technology infrastructure are more obsolete than what airlines use. One example is that the system needs to be reprogrammed city pair by city pair for each potential system-wide city pair when a change is made to the schedules, such as with the Floridian. This led to the inability for passengers to book Alexandria to points west of Washington, D.C. Another example is the number of steps agents need to use to accommodate a passenger asking for a different room in a sleeping car. It takes an experienced agent to prevent the price from increasing.
 
IMHO, the issue is that the bones of Amtrak's technology infrastructure are more obsolete than what airlines use. One example is that the system needs to be reprogrammed city pair by city pair for each potential system-wide city pair when a change is made to the schedules, such as with the Floridian. This led to the inability for passengers to book Alexandria to points west of Washington, D.C. Another example is the number of steps agents need to use to accommodate a passenger asking for a different room in a sleeping car. It takes an experienced agent to prevent the price from increasing.
The core system, ARROW, is a one-off based on a mid/late-1970s iteration of Sabre. It hasn't been modified much, just wrapped. Now they've pretty much lost anyone who had any real knowledge of it. To really improve things they need to do a rip and replace, which would be incredibly expensive. I wouldn't trust Amtrak IT to do it any more than I could throw a 1970s IBM mainframe. It would be a dream for an outfit such as Cognizant to do, though. They could run amok since Amtrak IT probably couldn't competently supervise and control them.
 
Yes, Amtrak does need a new reservations system. Our computer gurus can tell us how expensive that it is going to be. Personal experience of more than one medical facility having changed systems give only a thumb nail observation. They had 2 complete computer displays and key boards. Trying to get info from old system to new was awkward for clerks.
Cannot imagine a trip starting on theee old system and ending on the new. + how to handle delays cancellations over that implementation date.
 
Yes, Amtrak does need a new reservations system. Our computer gurus can tell us how expensive that it is going to be. Personal experience of more than one medical facility having changed systems give only a thumb nail observation. They had 2 complete computer displays and key boards. Trying to get info from old system to new was awkward for clerks.
Cannot imagine a trip starting on theee old system and ending on the new. + how to handle delays cancellations over that implementation date.
Ask United. They did such a migration.
 
Ask United. They did such a migration.
Or VIA, they recently replaced their core reservations system with a modern one, though they also call the new one ReserVIA. It was very late and at one point they pulled an already late implementation less than 60 days before the publicly announced implementation date. But they finally got it implemented earlier this year. Even then it wasn't smooth, but it's up.

From what I've been given to understand it is a somewhat customized version of a European rail reservations system. It wasn't built in house, which is seldom done in any type of industry or organization today.

I've been involved in a few core system replacements in my career and they are huge endeavors, are extremely fraught and difficult, take a lot of time and money, and are usually late. The easiest, which wasn't easy, the actual migration was done by a gradual "sell over" to the new system, with both the old and new system running side by side. It took five years after production implementation to complete the sell over. Far more difficult is a straight up conversion, converting all current operations and recent data in a big bang (you convert and load as much data as you can beforehand). Usually over a weekend with all IT staff on deck and biting their fingernails. That's what has to be done with a common carrier's reservations system. You cannot run two reservations systems at once for one carrier.

I am happy I was able to wait to reserve this year's VIA trip until after the new system was implemented, so my reservation didn't have to undergo conversion. I know something of how that sausage would be made, and didn't want to eat it.
 
Last edited:
Back
Top