7/19/15 is immediately and irredeemably ugly to me, because I'm not in the U.S. Quick, someone from Europe types in 9/10/15, do they want to travel in September or October?
This isn't an overnight batch process on a paper tape: It's the 21st century not 1962. Return both sets of results and let The user choose. Search is better than query.
If your solution to ambiguity of date input on a flight search website is to return flight options for either date, you will have a shocking number of customers inadvertently booking flights for the wrong dates, because they're already overwhelmed with a long list of options (airlines, times of day, prices, connecting points, etc.) If you added the randomizing variable of multiple entirely different dates being in play, all bets would be off.
If GUI's were not inherently ambiguous, the article would not have been written and we could all use hamburgers or ribbons or live tiles or material design and call it a day. But GUI's are and users have to deal with arbitary assumptions that are orthogonal to the business context.
If finding flights is a case of search, then we can look at Google. It uses text to maximize expressiveness. It uses progressive refinement rather than precise query to produce better results, e.g. maps results based on partial addresses. Google is understands that search has intrinsic ambiguity and that natural language is the best tool we have for dealing with it...and the hieroglyphs are not.