bug#61460: 30.0.50; Calendar shows eclipse for quarter moon

[Ulrich Mueller]

>>>>> On Mon, 13 Feb 2023, Michael Heerdegen wrote:

> Sorry if I am misunderstanding, but is this good enough?  Then I don't
> understand.  This doesn't go specifically to you only.

> What I understand is: there are two conditions that have to be met at
> the same time, and these are more or less independent over time: (1) the
> latitude of the moon has to be smaller than a certain angle, and (2) it
> has to be new moon or full moon.  Correct?

Yes.

> My questions:

> (1) AFAIU, the "phase name" is derived from one of four values of the
> moon "phase".  Is this really good enough to decide whether it is new
> moon or full moon?  AFAIU the four moon phases all have the same length.
> So AFAIU the test you added is not strong enough, we must first test
> whether it is full moon or new moon, only at these days can an eclipse
> happen, and only for these exact dates we need to check the moon's
> latitude for whether it is small enough for an eclipse.

The phase is passed to eclipse-check as an argument from lunar-phase:

| (lunar-phase INDEX)
|
| Local date and time of lunar phase INDEX.
| Integer below INDEX/4 gives the lunation number, counting from Jan 1, 1900;
| remainder mod 4 gives the phase: 0 new moon, 1 first quarter, 2 full moon,
| 3 last quarter.  Returns a list (DATE TIME PHASE).

eclipse-check is only called for the actual dates/times of the lunar
phases, and then checks for phase 0 ("Solar") or phase 2 ("Lunar").
IIUC this should guarantee that it is the exact date and time of new
moon or full moon.

> (2) https://en.wikipedia.org/wiki/Lunar_node tells that the limit for
> the longitude of the moon is different for lunar vs. solar eclipses.
> The same will be the case when we test the latitude.  The test we
> currently use doesn't reflect that.  Should it?

Probably. Also, the moon's orbit is elliptic, so one would expect the
latitude angles at perigee to be different from those at apogee.

Anyway, let's not the better be the enemy of the good. I've pushed the
patch to the emacs-29 branch (with updated tests, thanks Eli for
reminding me). Fixing the other issues would require much more work.

Are more precise prediction of eclipses within the scope of Calendar?
If yes, then this bug should be left open for a followup patch.