When Two Eclipse Predictors Disagree at the Path Edge

Update (July 2026): the root cause described below was later superseded. The Iceland/Spain disagreement wasn't actually explained by small x₀/y₀ Besselian-element differences between tools — it was an hour-angle bug in the contact solver that over-rotated every observer by Earth's rotation during ΔT. Reykjavík isn't a marginal graze at all: with the fix, it gets a genuine ~56 seconds of totality. See Four Seconds Early for the full story.

A user reached out last week asking why eclipseClick was showing Reykjavík as a partial eclipse for August 12, 2026, while Jubier's interactive map showed totality — 23 seconds of it. Same coordinates, same eclipse, different answers. That question sent me down a rabbit hole that exposed two bugs specifically affecting locations near the totality path limit.

Why tools disagree at the edge

The discrepancy isn't surprising on its own. eclipseClick and Jubier use independently sourced Besselian elements, and the x₀/y₀ coefficients that define the shadow axis position differ by small amounts — around 0.0001 fundamental-plane units, which translates to roughly 0.6 km in shadow position, or about 1 second of timing error. For a location well inside the path, this doesn't matter much. For a location 20 km from the path limit, it can flip the answer from "totality" to "partial."

Reykjavík sits north of the totality centerline, close to where the northern path edge crosses Iceland. Our smooth-limb solver computed m_max (the observer's closest approach to the shadow axis) just above |L₂| (the umbral radius) — barely outside the path. Jubier's elements place the path a few kilometers further north, putting Reykjavík just inside. Both answers are defensible given the element uncertainty; the tools simply disagree on which side of the edge the city falls.

But then I looked more carefully at how eclipseClick decides whether to attempt a C2/C3 solve at all. That's where I found the first bug.

Bug 1: A 57 km margin where 6 km was intended

The gate condition read:

if (mMax < Math.abs(L2max) * 1.5) {
  // attempt umbral solve
}

With a typical umbral radius of ~0.005 FP units, multiplying by 1.5 gives a threshold of 0.0075 — roughly 57 km beyond the actual path edge. The intent was a small guard for floating-point rounding, but the relative multiplier made it far too generous. Any observer within 57 km of the path limit would have the solver attempt to find C2 and C3 contact times, regardless of whether they were actually in totality.

For Reykjavík, the solver was attempting the umbral solve and returning null (no convergence) — correctly, since the user was outside the path. But for observers a bit closer to the edge, Newton-Raphson could find spurious solutions: contacts that satisfied the math without corresponding to any real physical event.

The fix is a fixed-offset guard sized to the actual source of imprecision — floating-point rounding in the geodetic-to-geocentric conversion, which is bounded at a few kilometers:

if (mMax < Math.abs(L2max) + 0.001) {  // ~6 km
  // attempt umbral solve
}

Bug 2: Limb corrections capped too tightly for graze-zone observers

Chasing the Reykjavík case surfaced a second problem. For observers inside the path but close to the edge — where totality lasts only seconds — lunar limb corrections can be large. When the shadow grazes an observer rather than crossing over them, a modest valley on the Moon's limb produces a much larger time shift than it would for a location near the path center. Published references cite 30–80 second corrections at path edges.

The limb correction engine had a hard cap of 18 seconds. Anything larger was silently discarded, and the observer got uncorrected smooth-limb times instead. For interior observers, 18 seconds is generous. For graze-zone observers, it was dropping the only corrections that mattered.

The cap is now 90 seconds — about 3× the worst documented graze-zone correction, large enough for real physics while still rejecting numerical runaway from DEM noise.

The practical upshot

For users with locations well inside the path, nothing changes. For graze-zone observers with limb corrections enabled, the corrected times may shift noticeably — and since scripts are stored as offsets from C2/C3 rather than absolute timestamps, no script recreation is needed. The timeline builder's totality budget check will surface any tightened windows automatically.

If you're observing from Iceland, northern Spain, or the Faroe Islands this August and your predicted totality duration shifted after updating, that's the limb correction cap being lifted. The new numbers are more accurate than what the app was reporting before.