Bump iers from 0.2.0 to 0.3.0

[dependabot]

Bumps iers from 0.2.0 to 0.3.0.

Release notes

Sourced from iers's releases.

v0.3.0

0.3.0 - 2026-09-06

Fixed

• DeltaT.at answers every date in 1972 again. The switch from the Espenak & Meeus polynomial to measured data was pinned to 1972-01-01, the start of the modern UTC era, but the bundled EOP series only starts at 1973-01-02, so the 367 days in between belonged to neither source and raised OutOfRangeError.

Changed

• DeltaT.at picks its source by asking what the loaded data actually covers rather than by calendar date. The EOP series is used wherever it reaches, the polynomial covers the rest of 1800–1986, and only a date outside both raises. A configured or extended series therefore moves the seam with it, and no fixed date can drift away from the data behind it again.

Two consequences for a series that does not span the query. A date past the end of a short series now returns a polynomial estimate if it falls before 1986, where it used to raise; this cannot arise with the bundled data, which ends decades beyond 1986. And a date outside both sources now raises with a message naming the polynomial range and the series range, instead of the EOP range alone, which read as if the caller had asked for something out of range when the polynomial covered it.

Where the polynomial and the series meet in the bundled data they differ by about 61 ms, well inside the polynomial's own error in that era.

• Pointing the gem at a different data file now takes effect. finals_path, leap_second_path and cache_dir memoised their parse on first read and never dropped it, so setting any of them after a lookup kept serving the previous file until IERS.reset!. Each now invalidates just the data it governs; interpolation, sources and download_timeout leave the parse in place, since they do not change which file is read, and a Configuration the gem is not reading through governs nothing.

• Data.clear_cache! drops the parse along with the files it deletes. It removed the cached files and left their contents in memory, so the process kept serving a deleted cache while Data.status already reported :bundled.

• Data.update! drops the parse for each source as soon as it downloads it. It replaced the files on disk but left the old contents in memory, so a process that had already read them carried on with the pre-download data.

• OutOfRangeError raised by DeltaT.at no longer carries an available_range. What the gem can answer is two disjoint spans, and naming one of them in a field called available range is the same thing that made the old message misleading. The message names both spans; requested_mjd is unchanged.

• Data.clear_loaded! raises ConfigurationError for a source it does not recognise, rather than clearing nothing and reporting success.

• DeltaT.at consults the EOP series for every query, so a finals file that fails to parse now raises ParseError even for a date the polynomial owns outright, where it used to answer without reading the file. A file that parses to no rows is a series covering nothing and still falls back to the polynomial. A corrupt data file is worth surfacing whichever query reaches it.

• Refreshed the bundled finals2000A.all and Leap_Second.dat snapshots from IERS. Final values now extend through 2026-08-27 (previously 2026-06-25) and predictions through 2027-09-04 (previously 2027-07-03).

Full Changelog: rhannequin/iers@v0.2.0...v0.3.0

Changelog

Sourced from iers's changelog.

0.3.0 - 2026-09-06

Fixed

• DeltaT.at answers every date in 1972 again. The switch from the Espenak & Meeus polynomial to measured data was pinned to 1972-01-01, the start of the modern UTC era, but the bundled EOP series only starts at 1973-01-02, so the 367 days in between belonged to neither source and raised OutOfRangeError.

Changed

• DeltaT.at picks its source by asking what the loaded data actually covers rather than by calendar date. The EOP series is used wherever it reaches, the polynomial covers the rest of 1800–1986, and only a date outside both raises. A configured or extended series therefore moves the seam with it, and no fixed date can drift away from the data behind it again.

  Two consequences for a series that does not span the query. A date past the end of a short series now returns a polynomial estimate if it falls before 1986, where it used to raise; this cannot arise with the bundled data, which ends decades beyond 1986. And a date outside both sources now raises with a message naming the polynomial range and the series range, instead of the EOP range alone, which read as if the caller had asked for something out of range when the polynomial covered it.

  Where the polynomial and the series meet in the bundled data they differ by about 61 ms, well inside the polynomial's own error in that era.

• Pointing the gem at a different data file now takes effect. finals_path, leap_second_path and cache_dir memoised their parse on first read and never dropped it, so setting any of them after a lookup kept serving the previous file until IERS.reset!. Each now invalidates just the data it governs; interpolation, sources and download_timeout leave the parse in place, since they do not change which file is read, and a Configuration the gem is not reading through governs nothing.

• Data.clear_cache! drops the parse along with the files it deletes. It removed the cached files and left their contents in memory, so the process kept serving a deleted cache while Data.status already reported :bundled.

• Data.update! drops the parse for each source as soon as it downloads it. It replaced the files on disk but left the old contents in memory, so a process that had already read them carried on with the pre-download data.

• OutOfRangeError raised by DeltaT.at no longer carries an available_range. What the gem can answer is two disjoint spans, and naming one of them in a field called available range is the same thing that made the old message misleading. The message names both spans; requested_mjd is unchanged.

... (truncated)

Commits

• 63430ec v0.3.0 release
• b416d92 Close the DeltaT.at gap between 1972 and the EOP series (#8)
• 5ddcfcb Keep vendor/ out of the automated data update PR (#9)
• d970371 Update data with latest values from IERS (#7)
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)