Subject: bug#45818: 28.0.50; Test solar-sunrise-sunset fails

From: Mattias Engdegård <[email-masked]>
Date: Wed, 13 Jan 2021 13:12:48 +0100

12 jan. 2021 kl. 23.09 skrev Basil L. Contovounesios <[email-masked]>:

> Agreed.  If this is the sort of stuff that gets you (or Stefan, CCed)
> out of bed in the morning, then you might also be interested in looking
> at lunar-test-phase-list.  I tried applying the same
> calendar-daylight-savings-starts trick in with-lunar-test, but that just
> brought down the difference in actual vs expected times from 2hrs to
> 1hr.

Let's give lunar-tests.el a go then. Stefan, what is the ground truth here? Where does the data come from?

(And what does "**  Eclipse **" mean? That the Moon intersects the Earth-Sun orbital plane without causing an actual eclipse? I can't be the only one confused by this.)

If https://stellafane.org/observing/moon_phase.html can be trusted, the times of day in the test are off by about one hour. The discrepancies are almost exactly one hour for new moons but a few minutes off for full moons. Thus it looks like the test numbers were produced from a test run in summer, which is consistent with the file creation date.

> My guess as to why this happens is because calendar-dst-find-data (or
> similar) calls current-time-zone without an explicit time zone argument,
> meaning tests can't truly specify a time zone other than the system's in
> general.

Could be -- if so, the code would benefit from an override for test purposes.

> Is this new wishlist bug report material, or are we happy to leave
> lunar-test-phase-list marked as unstable and forget about this?

Marking a test as unstable is tantamount to commenting it out. There needs to be an open bug or the problem is quickly forgotten.