That really isn't the type of input I was thinking of, though certainly that is a fairly easy problem to solve in a variety of ways. I'm more interested in being able to say something like 'Aug 2' or 'next Thursday', the way I can in Google Calendar.
Oh hey, that does work! I hadn't noticed that, good for them! Their calendar dropdown is also superior to most others in that it isn't a popover-style context menu but has been integrated into the interface so that I can see a visual representation of the dates I've chosen.
Now if only their site wasn't completely broken on mobile... :(
I fly twice a year. Why the hell would I want an app for a flight booking company? It's this sort of mentality that really gets my goat when it comes to mobile.
I don't get how this is non-logical compared to what I said earlier. 24hour is the same excuse as the empirical system, you can divide 12 by 2,3,4,6 thus it makes things easier. It's a different system than the metric one, we could have said that a day lasted 100hours and week 10days. It doesn't make it non-logical though, it's like changing the basis.
The original comment I replied to was suggesting that the date picker was a bad thing. My point is that it's better than any other method, since parsing a date correctly for all people in all situations in the way implied in that post is not possible. There will always be ambiguity over the date if the user chooses to use 'dd/mm/yyyy' or 'mm/dd/yyyy'. Chaking location, or locale isn't much use - we brits go to America on occasion, and they come over here. If you mark it as [dd/mm/yyyy] then you've just limited the usefulness of 'a free-form date that gets parsed smartly'.
You would handle that by looking at looking at a user's location settings and choosing the appropriate one. For example, if we detect your IP is in Germany, we would prompt "Would you like to see this site in German and change the currency to Euros?" If you say yes, then we would also localize the date formats.
> You would handle that by looking at looking at a user's location settings and choosing the appropriate one.
Great, now if I try to book a flight from Spain to Hungary while being in the US for some reason, I'm pretty much guaranteed to get the one date format which makes no sense whatsoever.
If you were in the US, we would use US conventions unless you had specified that you picked a different localized site (let's say the .es site) in which case we would switch to the conventions based on localization settings.
Did your browser ask for en_GB or en_US or fr_FR or whichever localization? What is your IP? With those two info, I can make an educated guess and print out the expected format mask near the input box.