Every trip plan is made of two kinds of number: the ones you typed, and the ones the plan worked out for you. You typed the hotel. The plan worked out that you'll get there at 19:40.
Almost every frustration with planning software lives on the seam between those two.
Why is the arrival time in my trip plan always wrong?
Because arrival time isn't a field. It's a result.
You never enter it. It falls out of everything else: where you're starting, what time you leave, how far the drive is, how fast that road actually goes, how long you linger at the stop before it, and โ on a multi-day trip โ what time you got going that morning. Change any one of those and the arrival time changes, along with the arrival time of everything downstream.
That's why it feels unreliable in a way that the other fields don't. A stop's name stays what you called it. Its arrival time is a running total that quietly re-adds itself every time you touch the plan.
What actually decides when you arrive?
Working forward, in order: the departure from the stop before, plus the drive between them.
The drive is the easy half โ distance and road speeds. The departure is where it gets interesting, because a departure is itself a result of how long you stayed. And how long you stayed can be a couple of different things. Forty-five minutes at a charger is a length of time. Two nights in a town is a count of nights. Those resolve differently: a duration resolves to arrival plus that duration, while a count of nights resolves to a departure on the morning after the last one.
Which raises the obvious question โ what time is that morning? In Fernweh, that's one setting (Trip Preferences), and it anchors every overnight departure you haven't pinned yourself. One number, stated once, instead of a guess repeated per stop.
So the chain is: what you stated โ what that implies โ what that implies. Arrival time is the last link, which is why it's the one that visibly breaks.
What happens when you pin an arrival time?
This is where planners have to make a real choice, and most of them dodge it.
You pin an arrival โ be at the ferry at 14:20, be at the hotel by 18:00 โ and you've now stated something that may contradict what the plan computed. Something has to give. The lazy options are to ignore your pin and keep the computed number, or to accept the pin and let the rest of the day silently become wrong.
Fernweh paces the day that leads up to the pin so the pin is actually met. The important part is what it's allowed to move: only the numbers it chose for you in the first place. A stop you dated yourself ends the walk backwards โ your pin isn't something the plan gets to negotiate with. If a stop can't absorb the slack, the slack passes one stop further back to somewhere that can.
That's the whole principle, and it's worth stating plainly:
The plan derives what you didn't state. It doesn't overwrite what you did.
It sounds obvious written down. It is not what most tools do. The common behaviour is to treat every number as equally fungible โ including the ones you took the trouble to enter โ because that's much easier than tracking which is which.
What if the drive can't make it?
Sometimes pacing isn't enough. The ferry is at 14:20, you're four hours away, and it's 11:30.
Then the plan says so, and names the shortfall. It doesn't quietly move your pin to a time it prefers, and it doesn't leave you to notice on the day.
Two details matter more than they might seem:
It isn't only about ferries. A missed sailing is the dramatic version, but "be at the hotel by 18:00 and the drive cannot make it" is the same defect and by far the more common one. The flag applies to any stop carrying a pinned arrival, whatever kind of place it is.
It isn't only about the last stop of the day. A stop you merely call at mid-afternoon is exactly where a booked slot usually sits โ a tour, a tasting, a check-in window. That's flagged like any other.
And the inverse is just as deliberate: a pin the plan can meet says nothing at all. No badge, no warning, no reassurance. Silence is the plan telling you it's fine, and a planner that congratulates you on every satisfied constraint quickly becomes a planner you stop reading.
Which numbers should a planner be allowed to change?
If there's one idea worth taking from this, it's that "who owns this number" is a question worth asking of any planning tool you use โ not just ours.
Three questions that separate the tools quickly:
- When you move a stop, does everything downstream re-time โ and can you see that it did? If the plan doesn't visibly recompute, it isn't a plan, it's a list.
- When you state a time, does it survive the next edit? Type a departure, change something upstream, and check whether your number is still there.
- When something is impossible, does it tell you before the day? A plan that only reveals a conflict when you're standing at the dock has told you nothing.
The reason arrival time is the hardest field is that it sits at the end of every chain, so it's where every unstated assumption finally surfaces. You can't make it easy. What you can do is be clear about which numbers belong to the traveller and which belong to the software โ and never, ever quietly move one of the first kind.
Most planning frustration isn't the software getting the arithmetic wrong. It's the software getting the ownership wrong.
Behaviour described here reflects Fernweh on iOS as of version 1.23.0, released 27 August 2026. Pinned-arrival pacing and the unreachable-arrival flag are live. Updated on release day: the slack this post described as still being refined now has a line of its own โ when the plan reaches a pinned arrival early, each departure leading back to the last stop you anchored yourself states the latest you could set off and still make it ("Depart by 10:40"). Header photo by Myznik Egor on Unsplash.