MAG L1B: round time_shift to int64 ns to preserve TT2000 precision#3107
Merged
sapols merged 2 commits intoIMAP-Science-Operations-Center:devfrom Apr 30, 2026
Merged
MAG L1B: round time_shift to int64 ns to preserve TT2000 precision#3107sapols merged 2 commits intoIMAP-Science-Operations-Center:devfrom
sapols merged 2 commits intoIMAP-Science-Operations-Center:devfrom
Conversation
…MAP-Science-Operations-Center#3102) float64 cannot represent int64 TT2000 epochs near 8e17 ns exactly, so adding a float time_shift_ns silently quantized the epoch values. Round to integer nanoseconds in shift_time and timeshift_vectors_per_second so the arithmetic stays on the int64 grid.
sapols
changed the title
maxinelasp
pushed a commit
to maxinelasp/imap_processing
that referenced
this pull request
May 1, 2026
…MAP-Science-Operations-Center#3107) float64 cannot represent int64 TT2000 epochs near 8e17 ns exactly, so adding a float time_shift_ns silently quantized the epoch values. Round to integer nanoseconds in shift_time and timeshift_vectors_per_second so the arithmetic stays on the int64 grid.
lacoak21
pushed a commit
to lacoak21/imap_processing
that referenced
this pull request
May 4, 2026
…MAP-Science-Operations-Center#3107) float64 cannot represent int64 TT2000 epochs near 8e17 ns exactly, so adding a float time_shift_ns silently quantized the epoch values. Round to integer nanoseconds in shift_time and timeshift_vectors_per_second so the arithmetic stays on the int64 grid.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #3102.
mag_l1b.pyhad two lines that multiplied a calibrationtime_shiftby1e9and left the result asfloat64:When that float was added to the
int64TT2000 epoch array (values near8e17ns), NumPy promoted everything tofloat64, which can't represent those integers exactly. So each epoch was silently quantized by ~20-100 ns. This adds sub-microsecond cadence jitter to every L1B epoch even when the calibration shift is effectively zero, and the noise propagates to L1C, L1D, and L2.The fix rounds the time shift to integer nanoseconds in both spots:
int64 + int64staysint64, so TT2000 precision is preserved. Everything else in those functions is unchanged.New tests
test_shift_time_preserves_int64_precisioncoversshift_timewith both a zero shift and a nonzero shift on TT2000-scale epochs. The zero-shift case is the most striking demonstration of the bug ("I added 0 and the values changed?"); the nonzero case proves the shift actually applies and stays integer.test_timeshift_vectors_per_second_preserves_int64_precisionis a separate test because it covers a different function and a different assertion shape (string equality on the formatted attribute).Test plan
test_mag_l1b.pysuite passes (9/9).pre-commit run --filesclean (ruff, codespell, numpydoc, mypy).