NavList:

Paul Hirose, you wroye:
"You have plenty of company. The JPL Horizons application does the same thing. However, in my Lunar program the Julian / Gregorian selection is manual. The switch to the latter, with its step adjustment and change to the leap year rules, in the name of the Pope, was so fraught with religious overtones that many nations rejected it until the 18th or even 20th centuries."

One of the first things I learned about the calendar in astronomy when I was a kid was that the whole world switched over in 1582. That's how it was spelled out in the Explanatory Supplement and other resources. But of course that just wasn't the case. The idea that the switch should be hardcoded at 1582 was always bizarre, and it's amazing that it's still done today. It's a lesson: astronomers aren't very good at history.

Your solution, Paul, is an excellent choice. Sean, your thinking --that you will now add calculations for every calendar on Earth ever invented in all of history-- will keep you busy until time itself comes to an end (ok, you didn't say you would add calculations for every calendar, but it's a slippery slope, and you're poised at the edge of the icy precipice!). Yet another alternative that works just fine is the Proleptic Gregorian Calendar. It's an awful name, but a simple concept: run the current calendar system back forever. Who cares if it doesn't match the journal entries from Samuel Pepys or whoever? Unless you're working up horoscopes, how much does it matter?? In truth, the best historical calendar is the sky itself, and you find out the "real" date not from calendrical computation, but by comparing the Moon's position with its best-estimated ephemeris position. One can waste a lot of time figuring out whether a nautical logbook, for example, is keeping local date or home port date, using civil days or sea days, and various other issues. But if there's any measure of the Moon's position, the date is locked.

And that reminds me, Sean, you mentioned implementing some polynomials for Delta-T. And they are NASA polynomials! OK, let's be clear here... They are Espenak polynomials, and sometimes Meeus polynomials, and sometimes Meeus-Espenak polynomials, but there's precious little "NASA" in them. Many other authors have defined unique polynomials for Delta-T, too. Unfortunately these things create an illusion of precision, and in many ways the polynomials solve a problem with a solution that's worse than the original problem. By their very nature, fitted polynomials "explode" --yes, wildly explode-- outside their declared ranges. You get nonsense... A simple list of Delta-T values is all that's needed. And what you want even more --if you're trying to extend your tools back more than a few centuries-- is some measure of the uncertainty in Delta-T. If Delta-T can be calculated to the nearest second from a polynomial, but objectively the estimate of the value may be out by a whole hour, then how do you handle that? How do you display that inescapable uncertainty? It's an interesting puzzle in the display of astronomical information...

Frank Reed
PS: The calendar change wasn't just a religious question, Catholic v. Protestants, either. It was a political power issue first of all. And there were major practical problems, too. If we drop 10 days from the calendar next month, will you generously reduce my rent by 35%? Or will it be 32.25% (10 out of 31 days)? Or maybe only 25% just too keep the math simple, and because the landlords always win. It could have led to riots in Britain and the American Colonies in 1752. Could have... but didn't... there were no calendar riots in 1752 outside legend... but. Study the screen caps --anything and everything makes its way into pop culture, including jokes about calendar riots.

File: