iers 0.2.0 → 0.3.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 4132b4709810d88306f0ea6bde33b1664d1fdbfeef985e0191cba65c98c01f8a
-  data.tar.gz: 5e3bef64e668f1320bc9c3876e571bf4bb452ea2df52cd09539303bafbf03ea0
+  metadata.gz: 39a64a5333955d6d28a26abc77c01371004f91b8fb8ca4b958f3ac5d415cca13
+  data.tar.gz: 1f219ef6f35bc93ab6263832546a3af6534a7d2a29007425cfa54b2abea6c284
 SHA512:
-  metadata.gz: c2bd5f8b1d3a088bc9aa8d822013a9c04570cea94c6036f080eb4d34d8ad53ac0346e6547092f5ce95fe61f95df6de32006e59371894e3b77768565be15354a1
-  data.tar.gz: 8b32049edecc0955026664f02cbf89a1af9d518050374538cbf1b1c3b08d572509b971d522a1d368490d6d07bcbd90bb807bd9fd5c4223d074431a60583244f5
+  metadata.gz: cd2df5b1019640ac16f44d7289a5af2721fc90bef064785921701992fd6798c96c94ce9ef9f34f69323e79baba9b4d2ab28310520045b18c7ac1332d63fc6b69
+  data.tar.gz: 42cc738efcb811f3f01f2de2d303d89b333a33ae394cbacc27f261cda39ab00e8e982ff2e3706eaac93b40a25a0e2522cfeb3d2dfe78c196137f7e3fbb8fd7b0

data/CHANGELOG.md

@@ -1,5 +1,69 @@
 # 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.
+
+- `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).
+
 ## 0.2.0 - 2026-07-25
 
 ### Added

data/README.md

@@ -167,9 +167,10 @@ entry.observed?      # => true
 
 ### Delta T
 
-Compute Delta T (TT − UT1). From 1972 onward the value is derived from IERS
-data; before 1972 (back to 1800) it uses Espenak & Meeus polynomial
-approximations:
+Compute Delta T (TT − UT1). Wherever the loaded EOP series reaches, the value is
+derived from IERS data. Outside it, Espenak & Meeus polynomial approximations
+cover 1800 to 1986. The bundled series starts at MJD 41684 (1973-01-02), so
+earlier dates are estimated; `measured?` and `estimated?` say which you got:
 
 ```ruby
 entry = IERS::DeltaT.at(Time.utc(2020, 6, 15))

data/Rakefile

@@ -31,7 +31,6 @@ namespace :data do
       abort "IERS data update failed"
     end
 
-    IERS::Data.clear_loaded!
     IERS::Data.ensure_fresh!(coverage_days_ahead: 90)
     IERS::Data.leap_second_entries
 

data/data/Leap_Second.dat

@@ -1,10 +1,10 @@
 #  Value of TAI-UTC in second valid beetween the initial value until
 #  the epoch given on the next line. The last line reads that NO
 #  leap second was introduced since the corresponding date 
-#  Updated through IERS Bulletin 71 issued in January 2026
+#  Updated through IERS Bulletin 72 issued in July 2026
 #  
 #
-#  File expires on 28 December 2026
+#  File expires on 28 June 2027
 #
 #
 #    MJD        Date        TAI-UTC (s)