Some back story … I use Sabre web services to read and extract travel data into a database. The data is used for a suite of travel related products and applications. If you’ve worked on travel applications, you know that it’s some wild west programming – data consistency is awful.

Web services was supposed to fix everything because now it’s structured data, no more screen scraping! Well, it is better than it was in the past but there are still problems.

Sabre web services has an odd bug that only strikes on the last day of the month AND your car/hotel segment starts on that day. See the PickUpDateTime below – it should be 2013 not 2014. (Notice that they have the ReturnDateTime correct.)

1
2
3
4
5
6
7
8

<OTA_TravelItineraryRS Version="2003A.TsabreXML1.15.1">
. . .
    <VehRentalCore PickUpDateTime="2014-07-31T16:30:00" PickUpDay="3" ReturnDateTime="2013-08-02T16:00:00">
      <PickUpLocation LocationCode="ATL" CodeContext="IATA" />
      <ReturnLocation LocationCode="JAX" CodeContext="IATA" />
    </VehRentalCore>
. . .
</OTA_TravelItineraryRS>

Since I’m running an older version of the TravelItinerary web service, thought I’d try the latest and greatest version available to see if the problem is fixed. As you can see below, Sabre’s solution is to drop the year. Nice. Are you kidding me? We went from the wrong date to an invalid ISO format across the board?

1
2
3
4
5
6
7
8

<TravelItineraryReadRS Version="2.2.0">
. . .
    <VehRentalCore PickUpDateTime="07-31T16:30" PickUpDay="3" ReturnDateTime="08-02T16:00">
      <DropOffLocationDetails LocationCode="JAX" />
      <LocationDetails LocationCode="ATL" />
    </VehRentalCore>
. . .
</TravelItineraryReadRS>

…I’d love to hear the reasoning behind that solution hack. Why is there such a lack of quality these days? I have some stories I want to post about this later…

Now I have to write new logic to decode this crap which will replace the old logic I had to fix the original crap.