Here's a suggested patch. Points to the list of contrib libs, removes information about how to create a new contrib project, and removes the section for maven configuration

The "favorite contrib" piece is covered on the new contrib_libs page too "If you find that active development for a library has ceased and you would like to take over as owner, please contact <mailto:[email protected]|[email protected]>. ..." so, yeah, taking that piece out instead seems like a good approach. Thanks!

OK, README updated.

wildwestrom.sidereal-time-clock.time-test
4 non-passing tests:

Fail in greenwich-mean-sidereal-time
Get GMST given the Julian date.

            Using reference values from XEphmem 4.0.1

expected: {:h 20, :m 31, :s 24}

  actual: {:h 20, :m 34, :s 30}          
    diff: - {:s 24, :m 31}          
          + {:s 30, :m 34}            


Fail in greenwich-mean-sidereal-time
Get GMST given the Julian date.

            Using reference values from XEphmem 4.0.1

expected: {:h 14, :m 55, :s 50}            

  actual: {:h 14, :m 58, :s 48}          
    diff: - {:s 50, :m 55}          
          + {:s 48, :m 58}            


Fail in greenwich-mean-sidereal-time
Get GMST given the Julian date.

            Using reference values from XEphmem 4.0.1

expected: {:h 16, :m 13, :s 23}            

  actual: {:h 16, :m 9, :s 26}          
    diff: - {:s 23, :m 13}          
          + {:s 26, :m 9}            


Fail in greenwich-mean-sidereal-time
Get GMST given the Julian date.

            Using reference values from XEphmem 4.0.1

expected: {:h 18, :m 48, :s 53}            

  actual: {:h 18, :m 50, :s 36}          
    diff: - {:s 53, :m 48}          
          + {:s 36, :m 50}            

And here’s my function

(defn greenwich-mean-sidereal-time
  "For longitude zero, calculates the sidereal time given a Julian day."
  [jd]
  (let [MJD0     2415020.0
        J2000    (- jd MJD0)
        GMST     (+ 18.697374558 (* 24.06570982441908 J2000))
        GMST-24h (mod GMST 24)]
    (sidereal-time-map GMST-24h)))

stating the obvious, but if you don't know the right answer for a given computation, you cannot possibly create a meaningful test for it :) either you'll have to take the old program's values as canon, or you'll have to understand your own program very carefully

an 'outside of the box' way to solving this might be jumping to a semi-related problem that would depend on the greenwich-mean-sidereal-time impl being correct. if the solution to the other problem is grossly incorrect, then that might give you a hint that greenwich-mean-sidereal-time is also incorrect

Hmmmm, that makes things difficult I guess. So I guess for now I’ll see if I can find a good reference implementation.

I’m thinking of using graalvm to link with an existing astronomy library.

I’m gonna have to revisit this another time.

Even if there have been such changes - nothing prevents you from not upgrading the transit libraries. Or from migrating the data upon an upgrade that's not backwards compatible.

I don't think it has, but they would hesitate too if they needed would be the idea.

I thought Freesian on the other hand was intended for persistent storage?

https://github.com/Datomic/fressian/wiki

You can also give Nippy a look: https://github.com/ptaoussanis/nippy I heard a lot of good things about it.