Skip to content

Fix GPS-to-UTC conversion around leap-second boundaries (fixes #192) - #200

Open
betaBison wants to merge 3 commits into
v1.1.1from
derek/fix-leap-seconds-issue-192
Open

betaBison wants to merge 3 commits into
v1.1.1from
derek/fix-leap-seconds-issue-192

Conversation

@betaBison

Copy link
Copy Markdown
Member

No description provided.

@codecov

codecov Bot commented Nov 4, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.61%. Comparing base (08cbf60) to head (c71c99a).

Additional details and impacted files
@@           Coverage Diff           @@
##           v1.1.1     #200   +/-   ##
=======================================
  Coverage   99.61%   99.61%           
=======================================
  Files          27       27           
  Lines        3899     3901    +2     
=======================================
+ Hits         3884     3886    +2     
  Misses         15       15           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@heathsanchez

Copy link
Copy Markdown

Thanks for addressing #192. I independently replayed the latest revision and obtained 685 passing offline repository tests, with four network-dependent tests excluded. An additional 19,818-case historical boundary check found no conversion errors.

I noticed two small hardening opportunities:

  1. The updated numeric get_leap_seconds() now returns 0 for NaN and 18 for positive infinity, whereas the previous implementation rejected those inputs. An explicit finite-value check would preserve fail-fast behavior.
  2. Several new epoch-millisecond assertions use default pytest.approx() or np.testing.assert_allclose() tolerances. At these timestamp magnitudes, those comparisons can accept errors substantially larger than one second. Explicit absolute tolerances with zero relative tolerance (or exact equality for integer milliseconds) would make the regression checks stronger.

I’ve also included a synthetic downstream prepare_kaggle_submission() regression in #201, which may be useful to incorporate regardless of which implementation is preferred.

Happy to help reconcile the tests and ensure the final fix has the strongest coverage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants