Stack._at() out-of-range exception only mentions final segment checked, instead of all segments available

[TheDaniel166]

In skyfield/jpllib.py, the Stack class is responsible for selecting the correct segment when a body is stored across multiple date ranges — for example DE441, which stores each body across two epochs. The scalar path in Stack._at() uses a for/break pattern to find the covering segment:

for segment in reversed(self.segments):
    spk = segment.spk_segment
    if spk.start_jd <= t.tdb <= spk.end_jd:
        break
return segment._at(t)

If no segment covers t.tdb — for example, a date that falls between segments or outside the kernel's full range — the loop exhausts without breaking and segment is left bound to the last segment iterated. segment._at(t) is then called on the wrong segment, returning a silently incorrect position with no error raised.

Expected behaviour
When no segment covers the requested date, Stack._at() should raise EphemerisRangeError — consistent with the behaviour of ChebyshevPosition._at() and consistent with the array path in Stack._at() itself, which correctly fills with nan for uncovered indices.

Actual behaviour
A wrong position is returned silently. No exception is raised. The caller has no way to detect that the result is incorrect.

Reproducer
Load DE441 and request a position at a date that falls outside any single segment's coverage but inside the kernel's nominal range. The scalar path will silently return the position from whichever segment happened to be last in the iteration, rather than raising.

Root cause
Python's for/break pattern does not raise on loop exhaustion — the loop variable retains its last value. The correct pattern is an explicit return inside the loop body and a raise after the loop:

for segment in reversed(self.segments):
    spk = segment.spk_segment
    if spk.start_jd <= t.tdb <= spk.end_jd:
        return segment._at(t)

start_time, end_time = self.segments[0].time_range(t.ts), self.segments[-1].time_range(t.ts)
raise EphemerisRangeError(
    'no segment in Stack covers the requested date',
    start_time[0], end_time[1], t, None
)

Asymmetry with the array path
The array path already handles this correctly — it fills with nan for unmatched indices and leaves the caller to detect gaps. The scalar path should at minimum raise rather than silently corrupt the result.

Note on ordering assumption
The current fix iterates reversed(self.segments), which implicitly assumes that the covering segment is more likely to be near the end of the list (i.e. modern-era segments appear last). This assumption holds for DE441's two-segment layout but is not guaranteed by the SPK format. A forward iteration with early return makes no ordering assumption and is equally efficient for the two-segment case.

Discovery context
This bug was discovered during the development and validation of Moira, a pure-Python astronomical engine that uses jplephem directly for DE441 kernel reads. Moira's SpkReader implements explicit epoch-aware segment selection — iterating all segments for a body pair and selecting the one whose start_jd ≤ jd ≤ end_jd, raising KeyError if no segment covers the date. Comparing Moira's behaviour against Skyfield's during validation revealed that the Stack scalar path could return without finding a covering segment.

A related segment-selection bug in jplephem itself — where kernel[center, target] naively returns the last matching segment regardless of date, giving wrong positions for historical epochs — was reported separately to the jplephem repository.

Environment
Skyfield version: current master
Ephemeris: DE441 (single-file, two segments per body)
Python: 3.11+

[brandon-rhodes]

Could you provide a short, complete Python script that illustrates the problem? I just wrote one, and was not able to reproduce the problem. I added this test to test_jpllib.py:

def test_range_error_of_multiple_matching_segments():
    ts = load.timescale()
    t = ts.utc(2026, 5, 1)
    eph = load_file(_data_path('./de441-1969.bsp'))

    mercury = eph['mercury barycenter']
    assert type(mercury).__name__ == 'Stack'
    assert len(mercury.segments) == 2

    with assert_raises(EphemerisRangeError, '1969-07-22 through 1969-07-30'):
        mercury.at(t)

with a suitable import at the top:

from skyfield.jpllib import EphemerisRangeError

The result was a passing test, because whichever segment is chosen by the loop you looked at, the segment itself will raise the correct error with asked for a date outside of its own range.

It will be interesting to see how your example code differs from this, and how it manages to cause the error.

[TheDaniel166]

I took another careful look at this, and I want to restate the issue more precisely.

First, thank you for checking it with a concrete test. Your 2026-05-01 example against de441-1969.bsp does show that, in that specific case, Skyfield raises EphemerisRangeError. So I agree that my original issue text was too broad in presenting DE441 as a reproducer for a silent wrong-value result.

After re-checking the segment layout and the downstream evaluator behavior more directly, I think the more accurate statement is this:

1. DE441 itself is not a good example of an uncovered inter-segment gap.
2. The control flow in Stack._at() still lacks an explicit “no matching segment” branch.
3. Because of that, correctness in the no-match case is being delegated to the downstream segment evaluator rather than enforced by Stack itself.

The part that led me to file the issue was this scalar path:

python
for segment in reversed(self.segments):
    spk = segment.spk_segment
    if spk.start_jd <= t.tdb <= spk.end_jd:
        break
return segment._at(t)

If no segment satisfies the predicate, the loop does not signal that explicitly; it falls through with segment still bound to the last iterated segment, and then calls segment._at(t) anyway. So the no-match condition is not handled at the Stack layer.

I then checked DE441 directly with jplephem to verify the actual segment layout and the segment boundary behavior. For SSB -> Mercury barycenter, the two DE441 segments are:

• -3100015.5 .. 2440432.5
• 2440432.5 .. 8000016.5

So they are contiguous. That means I should not have used DE441 as though it demonstrated a true uncovered gap between stacked segments.

However, the second thing I checked is what happens if one calls the segment evaluator just outside its advertised date range. In that direct probe, compute_and_differentiate() did not behave as a strict “reject immediately outside [start_jd, end_jd]” guard. It could still compute for a small overshoot beyond end_jd before eventually raising farther out.

That does not rescue my original DE441 example; I agree that example was wrong. But it does mean the exhausted-loop fallthrough in Stack._at() is still a real control-flow weakness in principle: if a Stack ever does contain an actual uncovered gap, or any other no-match case, Stack is not enforcing that condition explicitly. Instead it is relying on downstream segment behavior to catch it.

So the narrower and more accurate version of the report would be:

• not that “DE441 silently returns the wrong value in the example I gave”;
• but that “Stack._at() has no explicit no-match branch, and therefore does not itself enforce coverage when no segment matches.”

For comparison, in Moira’s SPK reader I handled split-epoch selection by iterating all candidate segments for a body pair, returning only when start_jd <= jd <= end_jd, and otherwise raising immediately before evaluating any segment. That was the behavior I expected here as well, and it is why this stood out to me during validation.

So I think the fair correction is:

• your test does refute my original DE441 reproducer as written;
• the underlying point I was trying to make is better framed as a control-flow / explicit-coverage-handling issue in Stack._at() itself.

If it would help, I am happy to rewrite the issue description so that it reflects this narrower claim instead of the original DE441 wording.

[brandon-rhodes]

Thanks for the response, I've at least updated the issue title so that I remember the exact issue: that the exception raised is raised by only one segment, that can only "see" its own date bounds, but that can't see the bounds of all the segments that were tried earlier in the loop; so the exception provides less information that it might.

I'll plan on adding an escape clause to the for loop that prevents fall-through and offers a more interesting exception message, that says something like "none of the N segments for TARGET overlap with the date D that you want" or something like that.