Here's a small thing that turns out to be a big thing.
You're in Copenhagen for three nights, then you take a train to Stockholm. Day four is the travel day. Where do you eat breakfast?
Obviously in Copenhagen — you wake up there. But ask most planning tools to build a nine-day Copenhagen-and-Stockholm trip and day four will be labelled "Stockholm," and everything on it will be in Stockholm, including a 7:30am breakfast in a city you don't reach until afternoon.
It's not a hallucination. Nothing on that day is fake. The restaurant is real, the address is right, the city is a city you're genuinely visiting. Every check we described in our post about venue verification passes. It's just an itinerary for a day you aren't having.
Why the day has two cities
A travel day is genuinely two days stapled together:
- Morning belongs to where you slept — breakfast, checkout, maybe one last thing near the hotel.
- The middle belongs to the journey — the train, the drive, the airport.
- Afternoon and evening belong to where you're going — check-in, dinner, a gentle first look around.
Software wants one city per day, because a day has one label and one weather forecast and one row in a database. Reality doesn't cooperate.
Where the plan actually comes from
We stopped asking the AI to figure this out and made it deterministic. The key realization: your hotels already know the answer.
If you've told us where you're staying and on what dates, then for any given night we can work out exactly which bed you're in — and therefore what city you wake up in, and which day is the one where those two things differ. That day is the travel day. Not because a model decided it, but because your reservations say so.
From there the day gets built backwards from real constraints: breakfast lands in the departure city, checkout goes where checkout goes, the journey occupies the middle, check-in anchors the afternoon, and dinner belongs to the arrival city.
The parts that bit us
Three things we learned the hard way, all from real trips:
Same city, two names. A hotel saved through autocomplete stores the local name — "København" — while the destination search stores the English one, "Copenhagen." To a string comparison those are different cities, so the hotel stopped counting as a bed, and the whole travel-day boundary slid a day late. Someone's plan had them eating dinner in Denmark on the evening they were actually in Sweden.
Two cities, one name. The exact opposite, a day later. Someone planned a genuine Charleston, West Virginia → Charleston, South Carolina trip. Comparing the city name alone merged them into one nine-day blob, and the plan drifted 500 miles across state lines mid-week. The fix has to tell "same city, two languages" apart from "two cities, same name" — and those pull in opposite directions.
Driving days need the middle filled. On a road trip the journey isn't dead time, it's the good part. If you're driving four hours through southern Utah, the itinerary should know about the overlook an hour in. So for driving legs we ask for the actual route and look for worthwhile stops along it — with a sanity check, because when the origin city is ambiguous you can end up with a "quick stop" that's 3,000 miles off course. Ask us how we know.
Why bother
Because the travel day is the one most likely to go wrong in real life, and the one where a bad plan costs you the most. Miss breakfast because the itinerary put it in the wrong country and you're starting a travel day hungry, annoyed, and no longer trusting the thing in your pocket.
Get it right and nobody notices. That's the goal, honestly. The best possible outcome for this feature is that you never think about it.