A Schedule or ScheduleList under a fixed timestep resolves up to one full dt before the time it was asked for.

Schedule(t_start=0.05, t_period=0.1) with dt=0.01 fires at 0.04, 0.15, 0.24, 0.35 instead of 0.05, 0.15, 0.25, 0.35. ScheduleList(times_evt=[0.07, 0.13, 0.29]) fires at 0.06, 0.13, 0.29. Which entries slip depends on how the accumulated step time rounds, so it is intermittent rather than a constant offset.

detect(t) is called with t at the end of the step, and the fixed-step branch resolves at self.time + ratio * dt — ratio is a position within the step, 0 at its start and 1 at its end. When the schedule sits exactly on t, both detect methods return ratio = 0.0, placing the event at the start of the step: a whole dt early.

Both return 1.0 now. ZeroCrossing already used that convention for its own exact-hit case (return True, True, 1.0), so this makes the two event families agree.

The other close branch (_t >= t_next, the event was already passed) keeps 0.0 — there the event really does belong at the start of the step.

Only the fixed-step path is affected. The adaptive branch resolves close events at time_dt and ignores ratio, so nothing changes there beyond the ordering in _detected_events, which is sorted by ratio and now reflects the actual order.

TestWrapper.test_trigger_event asserted the old literal and is updated. Added coverage: the exact-hit ratio for both classes, and an end-to-end check that a schedule off the step grid fires at the requested times (to 1e-12).