Add Julian calendar dates for earlier historical calculations

[willismonroe]

It would be useful if the Skyfield library had the ability to convert to Julian dates for periods before the Gregorian calendar in order to more closely align with historical calculations of astronomical observations.

(see discussion here: https://stackoverflow.com/questions/63855845/differences-between-pyephem-and-skyfield-for-calculating-ancient-phenomena/63865680?noredirect=1#comment112978745_63865680)

[brandon-rhodes]

Thanks for opening an issue! I'll see if I can get to this within the next few weeks.

[willismonroe]

Great, let me know if I can help or test anything along the way.

[brandon-rhodes]

@willismonroe — All right, I think I have something working! If you install Skyfield from the repository:

pip install https://github.com/skyfielders/python-skyfield/archive/master.zip

— then you should be able to tell your Timescale object on what Julian date you want it to switch from the Julian calendar to the Gregorian calendar. Constants are provided for two common choices: the adoption by the Church in Rome, and the adoption by the English. Thus:

from skyfield import api

ts = api.load.timescale()
ts.julian_calendar_cutoff = api.GREGORIAN_START  # in Rome

print(ts.tt_jd(2299159.5).tt_strftime())
print(ts.tt_jd(2299160.5).tt_strftime())

print(ts.utc(1582, 10, 4).tt)
print(ts.utc(1582, 10, 15).tt)

print(ts.utc(1582, 10, 15) - ts.utc(1582, 10, 4))

Could you try it out and see if it works for you? The cutoff setting should affect all calendar inputs and outputs, assuming I didn't miss any. Thanks!

[brandon-rhodes]

@willismonroe — I will be away from the keyboard next week, and so instead of doing a Skyfield release for this feature and then perhaps being unavailable if there's a problem, I am planning to hold Skyfield at 1.27 until my return. So there's no rush to test this feature within the next couple of days! I'll check again when I'm back at the keyboard at the end of next week, and consider making a release then.

[willismonroe]

@brandon-rhodes no worries! I've been quite busy, hoping to test this soon!

[brandon-rhodes]

I have just released Skyfield 1.28 which includes this new feature across all calendars support by the timescale object:

https://rhodesmill.org/skyfield/time.html#ancient-and-modern-dates

Let me know if you run into any problems. Enjoy!

[willismonroe]

Hi @brandon-rhodes this works perfectly:

I was able to calculate the new moons for 537 BCE matching Parker and Duberstein's calculations from 1942 (off by one day, but that's fine for what I'm doing).

By the way, I had to add a numpy.array.any() to timelib.py so that I could pass a time range to ts.tt(). Line 799 for me now reads:

if (julian_before is None) or array(J >= julian_before).any():

that's probably not the right way to do it, and I can certainly see problems when your date range cross the Gregorian start date...

[brandon-rhodes]

@willismonroe — Thank you for altering me to this bug! I have just pushed a fix, along with a test to try to keep it fixed. Could you try installing the development version of Skyfield to try it out on your machine?

pip install https://github.com/skyfielders/python-skyfield/archive/master.zip

Thanks!

[willismonroe]

Can confirm, works as expected.

By the way, is there a reason that Time.tt doesn't return a CalendarTuple like Time.utc? It would make string formatting easier.

[brandon-rhodes]

Does .tt_calendar() or .tt_strftime() do what you need, or is neither of them quite what you are looking for?

[willismonroe]

They do, but the convenience of `Time.utc.month` (year, day etc...) is nice.

…

On Fri, Sep 25, 2020 at 11:37 AM Brandon Rhodes ***@***.***> wrote: Does .tt_calendar() or .tt_strftime() do what you need, or is neither of them quite what you are looking for? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#450 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFOTSXJETZRBCLSJCHBBDDSHTPOZANCNFSM4RPSGZAA> .

[brandon-rhodes]

Oh, I see! I hadn't realized that the other calendar routines were returning normal tuples instead of the special calendar tuples.

If you’ll open an issue, I can see about adding those fields to Skyfield within the next few weeks. Thanks for the idea!

[brandon-rhodes]

@willismonroe — Oh, and: I'm a bit worried that those dates are off so consistently by one day, except for maybe one date that instead agrees exactly? I suppose Cyrus was in a time zone several hours earlier than Greenwich, but I still would have expected at least ¾ of the events to line up on the same dates.

[willismonroe]

Yeah, well to be honest, I'm really not sure how Parker and Duberstein calculated their results, so it could just as easily be that they had an off-by-one error in 1942. It's an interesting problem though and one well suited to this library. I.e. the new month began when the crescent moon was first visible after sunset, so theoretically it shouldn't be too hard to create a method to print out Babylonian dates.

…

On Fri, Sep 25, 2020 at 11:54 AM Brandon Rhodes ***@***.***> wrote: @willismonroe <https://github.com/willismonroe> — Oh, and: I'm a bit worried that those dates are off so consistently by one day, except for maybe one date that instead agrees exactly? I suppose Cyrus was in a time zone several hours earlier than Greenwich, but I still would have expected at least ¾ of the events to line up on the same dates. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#450 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFOTSQ6Z2OZLFNE2FOQKLTSHTRPRANCNFSM4RPSGZAA> .

[brandon-rhodes]

@willismonroe — That's true, the orbit parameters would not have been as exact in 1942!

And I just thought of something else: dates that long ago are going to be several hours (I think? at least a few dozen minutes?) off of the midnight/noon schedule of our modern atomic clocks, so TT and TAI will be way off from what folks at that time actually experienced as midnight, sunrise, noon, and sunset. It’s UT1 that might provide a guess as to where the day really stood back then. Could you try UT1 and see what your script prints?

[willismonroe]

Hmm, I'm unable to iterate over a UT1 Time array:

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-c4978c2e661b> in <module>
      8 r = ts.ut1(start_year, 1, range(1,365))
      9 print(f"New moons for year {abs(start_year)+1} BCE:")
---> 10 for time in r:
     11     e = earth.at(time)
     12     _, slon, _ = e.observe(sun).apparent().ecliptic_latlon()

~/.local/lib/python3.8/site-packages/skyfield/timelib.py in __getitem__(self, index)
    346             value = getattr(self, name, None)
    347             if value is not None:
--> 348                 setattr(t, name, value[index])
    349         return t
    350 

TypeError: 'float' object is not subscriptable

I looked into it, and the value is just 0.0 when name is ut1_fraction, for the other two names it's a full array of the fractions.

[brandon-rhodes]

@willismonroe — You are doing an exemplary job of finding bugs! Wow! I've submitted a patch, can you try a fresh install?

pip install https://github.com/skyfielders/python-skyfield/archive/master.zip

Thanks!

[brandon-rhodes]

(As it's Friday night and I will be away from keyboard starting tomorrow, I'll go ahead and cut a release to fix at least these two problems!)

[willismonroe]

Just tested out the new release (1.29) and it fixed all of my current issues. I'm still seeing a 1-2 day gap with this historical data, but there are lots of unknowns. For instance visibility above the horizon. I know the Skyfield altaz() method takes refraction into account, but I don't know how the authors of the data I'm using as a comparison calculated this. So I'm not too worried about the discrepancy. I'll keep testing with other historical data and report any issues I find.

…

On Fri, Sep 25, 2020 at 5:55 PM Brandon Rhodes ***@***.***> wrote: (As it's Friday night and I will be away from keyboard starting tomorrow, I'll go ahead and cut a release to fix at least these two problems!) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#450 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFOTSTDUJIHIL4FSAG65HLSHU3Y7ANCNFSM4RPSGZAA> .