NavList:

Antoine, you wrote:
"the statement given in the in the referenced post - i.e. “ Thus, the multiplier to convert minutes of arc to minutes of time is about 1/.271 = 3.7 for that observation. “ - is entirely true."

No. It is not. As I mentioned previously, the flaw here is that Paul H. looked at the topocentric lunar distance. It's that spooky parallactic retardation that caused George Huxtable so much angst way back in 2004 (and earlier). The way this appears when you clear a lunar for UT (instead of just looking for the error at a known UT, which is what nearly all modern lunarian enthusiasts are doing) is in the calculated altitudes. If you go in with observed altitudes, shot with a sextant, the clearing process removes the effect of the Moon's parallax properly. But if you accept variable computed altitudes, then you get a different parallax every time. The Moon's changing parallax then can partially cancel out the steadily incrementing distance between Venus and the Moon. It creates an illusion that somehow lunars are less accurate than people thought they were historically. One might imagine, "Stupid Maskelyne, Bowditch, Chauvenet! The lot of them couldn't see it!" But, no, of course they knew what they were doing (at least in this basic matter).

So how do we see this in the example under consideration? Although altitudes were not included, we can easily see what they would have to be for this lunar observation. Assuming height of eye equal to zero (as stipulated in your setup), we can see that the altitudes should be 38°46' for the Moon (LL in this case) and 30°10' for Venus. Enter GMT (UT) as 22:10:00 and 15°35.02' for the observed distance. Run the clearing and you get error = 0.00' (the extra digits are implied). All good, right? Notice that with the altitudes entered the web app automatically uses those entered altitudes.

Now we imagine an error in the observation of the lunar distance itself. So we change that to 15°34.02'. An error of exactly one minute of arc in the observed distance. But we leave the observed altitudes alone. This is the critical step. Run the clearing again with the same altitudes and the same GMT/UT, and you will see an error of exactly -1.00' just as you would expect. Now go ahead and adjust the GMT to make that error disappear.  You should find a time of 22:07:44. Thus a one minute error in the observed distance yields a 2.25 minute error in GMT/UT. This is relatively close to the "normal" 2.0 for a lunar. And the primary reason that it's above 2.0 is because the Moon itself was moving rather slowly in its orbit on this date since the Moon was at apogee.

The very large multiplier of 3.7, nearly double the normal relationship, that Paul Hirose quoted and which you attempted to validate, is not relevant except in some unusual ways of dealing with lunar observations. I wrote in my reply to Paul a week ago: "The rate of change of the topocentric distance does have some relevance in narrow cases, but it's really not the right way to look at the sensitivity to errors in observed lunars in most cases." And you can now see one of those cases. If you don't measure the altitudes, then the computation process generates different altitudes for each possible UT that you enter which changes the parallax. Historically, a handful of resources claimed that greater accuracy could be achieved by calculating altitudes (confusing precision with accuracy!), and anyone who followed that advice would have fallen into this trap where lunars would have been significantly more sensitive to small errors in the observed distance. There's bad advice in every century...

For anyone new to lunars or anyone who hasn't thought about lunars in a while and is now nervous that this is some new wrinkle, some new complexity... no. Just ignore it. This whole business is a very minor sidebar. In the modern world, we're not calculating GMT/UT from lunars so we don't need to worry about the altitudes. We can let the tools calculate them (as my web app does) since we know where we are and what time it is. As for cases in old logbooks, historically altitudes were almost always observed so the problem rarely arose.

Frank Reed
Clockwork Mapping / ReedNavigation.com
Conanicut Island USA