NavList:

Bill Ritchie, you wrote:
"Frank's Lunars Calculator, tweaked to extract the extra decimal place, gives -04° 51.84' , midway between the two!"

That extra decimal place is valid to about half an order of magnitude. The ephemeris data underlying my lunars web app is generally accurate to the nearest second of arc and no better. This is obviously plenty of accuracy for any problem in celestial navigation. The minutes here should be understood as somewhere in the range 51.82 to 51.86.

There are a number of small corrections that are usually ignored in celestial navigation which are larger than a second of arc. For example, DOV (deflection of the vertical, due to gravitational variations) is ignored by nearly all traditional celestial navigation apps and tools (DOV is included in my GPS Anti Spoof apps). DOV is frequently larger than a second of arc, and in some critical areas it is larger than a minute of arc. Another example, in lunars, would be the variation in the lunar limb. There are various large depressions and plateaus around the Moon's limb whose prominence changes with the libration cycle. These would change lunar distances by as much as a couple of seconds of arc, but no one has yet incorporated such corrections into lunars analysis software and apps (and no, this is not the same as adjusting an occulation for the lunar limb since an occultation occurs at an exact location on the lunar limb).

Paul Hirose noted that a one second change in Delta-T corresponds to a 0.5 arc second change in the position of the Moon (this is relative to the "background" celestial sphere). Just so we're clear here, this is nothing more than the usual motion of the Moon which can be approximated as "the Moon moves its own diameter in one hour". In angular terms, that's essentially 30' of arc in 60m of time. And that same two-to-one relationship follows when you divide both sides by 60 and then 60 again. Divide by 60 once: 0.5 minutes of arc in one minute of time. Divide by 60 again: 0.5 secconds of arc in one second of time. An error in Delta-T is nothing more than a watch error --an incorrect correction from "real physics time" (which is realized in practice as atomic clock time) to the UT standard. And it's not necessary to fuss over exact values for Delta-T if you're creating celestial navigation software: two seconds error in Delta-T leads to one arcsecond error in the position of the Moon. All other bodies show considerably smaller errors since their angular rates of motion are much smaller.

Unfortunately, among homebrew software and app developers, there has been a hunger for "polynomials" for Delta-T. These are a reflection of a 1980s approach to software development in which a piece of software (an "app") is developed, delivered to customers, and then becomes the property of users who are thereafter detached from the developers. In that model, a software developer had to "predict the weather". And that's really what we're talking about here. The meandering changes in Delta-T over the years, that wobbling clock error connected to minute fluctuations in the Earth's rotation, are driven in part by weather patterns on the Earth. These are not generally predictable in any useful way. Attempts to derive long-term polynomials are delusions, divinations, and barely science at all. But because we, as developers, are accustomed to the 1980s model of product development, we imagine that we must have a predicted value for Delta-T in our products that will be functional decades in the future. This is, of course, something that you can include as a baseline starting point, but there's no call for exact values, no need for some cleverly-crafted polynomial. An annual list of reasonable expectations is all that's really needed. And that list should be adjusted as new data for correct Delta-T values become available. 

Here's a list of Delta-T values (these are the ones used in my code):
DeltaT(2010) = 66.1 
DeltaT(2020) = 69.5 
DeltaT(2030) = 73
DeltaT(2040) = 77 
DeltaT(2050) = 81 

I use a "first-order polynomial" between listed values :). In other words, plain-old linear interpolation during a decade is sufficient. The values for the current decade can be adjusted as desired, as often as necessary, and I do this on a regular basis since the web app is not "delivered" in the sense of traditional software. 

Do we need to know the value of Delta-T today for the year 2037 (as in the example comparison originally posted)? No. And we shouldn't pretend that we have accurate predictions for Delta-T two decades into the future. But if Delta-T in the year 2037 is wrong by six seconds, and it might be (when we get there, if we get there), this would impact the position of the Moon at the usual two-to-one rate (60m:30' or 1m:0.5' or 1s:0.5") implying that the Moon's position would be off by only three seconds of arc. So even if, for some strange reason, you chose to print lunar altitudes or lunar distance tables for a date twenty years in the future, and even if your Delta-T prediction was substantially wrong, your tables would still count as "high-quality" for manual celestial navigation.

By the way, this should suggest another question: why can't you buy the Nautical Almanac for the year 2025 today?? In the 1770s, when voyages might take years, nautical almanac production was up to five years ahead of the calendar. Why can't we have that today? The official copyright-holder (HMNAO) releases the almanacs less than six months before the calendar year and part of the reason is an over-zealous concern about exact Delta-T values. But as un-official sources challenge or defy that claim of copyright and as users become less worried about proper "data provenance", you can expect that nautical almanacs will be available at least five or even ten years ahead with only trivial reduction in accuracy.

Frank Reed