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

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

[Basil L. Contovounesios]

X-Debbugs-Cc: Mattias Engdegård <mattiase@acm.org>

The following test has been failing for me, probably since it was
introduced:

--8<---------------cut here---------------start------------->8---
Running 1 tests (2021-01-12 15:11:42+0000, selector ‘(not (or (tag :expensive-test) (tag :unstable)))’)
Test solar-sunrise-sunset backtrace:
  signal(ert-test-failed (((should (< (abs (- sunrise 7.27)) epsilon))
  ert-fail(((should (< (abs (- sunrise 7.27)) epsilon)) :form (< 1.003
  #f(compiled-function () #<bytecode 0x121b36c341caac2>)()
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name solar-sunrise-sunset :documentation n
  ert-run-or-rerun-test(#s(ert--stats :selector (not (or (tag :expensi
  ert-run-tests((not (or (tag :expensive-test) (tag :unstable))) #f(co
  ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable)))
  ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
  eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
  command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/calendar/solar-tests
  command-line()
  normal-top-level()
Test solar-sunrise-sunset condition:
    (ert-test-failed
     ((should
       (<
	(abs ...)
	epsilon))
      :form
      (< 1.0033333324640985 0.016666666666666666)
      :value nil))
   FAILED  1/1  solar-sunrise-sunset (0.001369 sec)

Ran 1 tests, 0 results as expected, 1 unexpected (2021-01-12 15:11:42+0000, 0.071452 sec)

1 unexpected results:
   FAILED  solar-sunrise-sunset
--8<---------------cut here---------------end--------------->8---

The failure corresponds to the following line in the test:

  (should (< (abs (- sunrise 7.27)) epsilon))

At that point, sunrise-sunset has the following value:

  ((6.266666667535901 #1="IST") (16.716666667722166 #1#) "10:26")

In case it matters, my time zone is currently GMT +0000, and IST can
also refer to Irish Standard Time here.  I tried binding
calendar-{standard,daylight}-time-zone-name to "+0530" in the test, but
that didn't change anything.  Any ideas?

Thanks,

-- 
Basil

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
 of 2021-01-12 built on tia
Repository revision: ca024b0575c4ea754c4c6e6dbf21ed610e0d1fb8
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
System Description: Debian GNU/Linux bullseye/sid

Configured using:
 'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache
 --prefix=/home/blc/.local --enable-checking=structs
 --with-x-toolkit=lucid --with-file-notification=yes --with-x'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11
XAW3D XDBE XIM XPM LUCID ZLIB

Important settings:
  value of $LANG: en_IE.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml easymenu mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo x-toolkit x multi-tty make-network-process emacs)

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

[Mattias Engdegård]

12 jan. 2021 kl. 17.28 skrev Basil L. Contovounesios <contovob@tcd.ie>:

> At that point, sunrise-sunset has the following value:
> 
>  ((6.266666667535901 #1="IST") (16.716666667722166 #1#) "10:26")

On my machines (sitting in CET) it is

((7.2666666666045785 "IST") (17.716666666790843 "IST") "10:26")

and the time zone names don't seem to matter for the numerical results today, but maybe it depends on when it's run. In any case we should probably use something less ambiguous than IST (which is apparently also used for Israeli standard time).

I've been unable to reproduce your results but am not sure how to go about doing so exactly; running with TZ=GMT does not alter the results.

Could you try tracking down the origin of those numbers? Here is a trace of some of the relevant functions on my machines:

1 -> (solar-sunrise-sunset (12 30 2020))
| 2 -> (solar-exact-local-noon (12 30 2020))
| | 3 -> (solar-julian-ut-centuries (12 30 2020))
| | 3 <- solar-julian-ut-centuries: 0.2099520876112252
| 2 <- solar-exact-local-noon: ((12 30 2020) 6.9905251059993585)
| 2 -> (solar-julian-ut-centuries (12 30 2020))
| 2 <- solar-julian-ut-centuries: 0.2099520876112252
| 2 -> (solar-sidereal-time 0.2099520876112252)
| 2 <- solar-sidereal-time: 6.592887211896198
| 2 -> (solar-sunrise-and-sunset (0.2099520876112252 6.9905251059993585) 1.0 75.8 0)
| 2 <- solar-sunrise-and-sunset: (6.5198219809993585 18.46122823099936 11.941406250000002)
| 2 -> (solar-sunrise-and-sunset (0.2099520876112252 6.9905251059993585) 26.9 75.8 -0.61)
| 2 <- solar-sunrise-and-sunset: (7.2698219809993585 17.71122823099936 10.441406250000002)
| 2 -> (dst-adjust-time (12 30 2020) 7.2698219809993585)
| 2 <- dst-adjust-time: ((12 30 2020) 7.2666666666045785 "IST")
| 2 -> (dst-adjust-time (12 30 2020) 17.71122823099936)
| 2 <- dst-adjust-time: ((12 30 2020) 17.716666666790843 "IST")
| 2 -> (calendar-date-equal (12 30 2020) (12 30 2020))
| 2 <- calendar-date-equal: t
| 2 -> (calendar-date-equal (12 30 2020) (12 30 2020))
| 2 <- calendar-date-equal: t
1 <- solar-sunrise-sunset: ((7.2666666666045785 #1="IST") (17.716666666790843 #1#) "10:26")

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

[Basil L. Contovounesios]

[-- Attachment #1: Type: text/plain, Size: 3085 bytes --]

Mattias Engdegård <mattiase@acm.org> writes:

> Could you try tracking down the origin of those numbers? Here is a trace of some
> of the relevant functions on my machines:
>
> 1 -> (solar-sunrise-sunset (12 30 2020))
> | 2 -> (solar-exact-local-noon (12 30 2020))
> | | 3 -> (solar-julian-ut-centuries (12 30 2020))
> | | 3 <- solar-julian-ut-centuries: 0.2099520876112252
> | 2 <- solar-exact-local-noon: ((12 30 2020) 6.9905251059993585)
> | 2 -> (solar-julian-ut-centuries (12 30 2020))
> | 2 <- solar-julian-ut-centuries: 0.2099520876112252
> | 2 -> (solar-sidereal-time 0.2099520876112252)
> | 2 <- solar-sidereal-time: 6.592887211896198
> | 2 -> (solar-sunrise-and-sunset (0.2099520876112252 6.9905251059993585) 1.0 75.8 0)
> | 2 <- solar-sunrise-and-sunset: (6.5198219809993585 18.46122823099936 11.941406250000002)
> | 2 -> (solar-sunrise-and-sunset (0.2099520876112252 6.9905251059993585) 26.9 75.8 -0.61)
> | 2 <- solar-sunrise-and-sunset: (7.2698219809993585 17.71122823099936 10.441406250000002)
> | 2 -> (dst-adjust-time (12 30 2020) 7.2698219809993585)
> | 2 <- dst-adjust-time: ((12 30 2020) 7.2666666666045785 "IST")
> | 2 -> (dst-adjust-time (12 30 2020) 17.71122823099936)
> | 2 <- dst-adjust-time: ((12 30 2020) 17.716666666790843 "IST")
> | 2 -> (calendar-date-equal (12 30 2020) (12 30 2020))
> | 2 <- calendar-date-equal: t
> | 2 -> (calendar-date-equal (12 30 2020) (12 30 2020))
> | 2 <- calendar-date-equal: t
> 1 <- solar-sunrise-sunset: ((7.2666666666045785 #1="IST") (17.716666666790843 #1#) "10:26")

Here's my version of this trace:

1 -> (solar-sunrise-sunset (12 30 2020))
| 2 -> (solar-exact-local-noon (12 30 2020))
| | 3 -> (solar-julian-ut-centuries (12 30 2020))
| | 3 <- solar-julian-ut-centuries: 0.2099520876112252
| 2 <- solar-exact-local-noon: ((12 30 2020) 6.9905251059993585)
| 2 -> (solar-julian-ut-centuries (12 30 2020))
| 2 <- solar-julian-ut-centuries: 0.2099520876112252
| 2 -> (solar-sidereal-time 0.2099520876112252)
| 2 <- solar-sidereal-time: 6.592887211896198
| 2 -> (solar-sunrise-and-sunset (0.2099520876112252 6.9905251059993585) 1.0 75.8 0)
| 2 <- solar-sunrise-and-sunset: (6.5198219809993585 18.46122823099936 11.941406250000002)
| 2 -> (solar-sunrise-and-sunset (0.2099520876112252 6.9905251059993585) 26.9 75.8 -0.61)
| 2 <- solar-sunrise-and-sunset: (7.2698219809993585 17.71122823099936 10.441406250000002)
| 2 -> (dst-adjust-time (12 30 2020) 7.2698219809993585)
| 2 <- dst-adjust-time: ((12 30 2020) 6.266666667535901 "IST")
| 2 -> (dst-adjust-time (12 30 2020) 17.71122823099936)
| 2 <- dst-adjust-time: ((12 30 2020) 16.716666667722166 "IST")
| 2 -> (calendar-date-equal (12 30 2020) (12 30 2020))
| 2 <- calendar-date-equal: t
| 2 -> (calendar-date-equal (12 30 2020) (12 30 2020))
| 2 <- calendar-date-equal: t
1 <- solar-sunrise-sunset: ((6.266666667535901 #1="IST") (16.716666667722166 #1#) "10:26")

So I'm guessing dst-adjust-time adjusts for DST in my locale (based on
some cache), but not yours?  The following change lets the test succeed
for me:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: dst.diff --]
[-- Type: text/x-diff, Size: 648 bytes --]

diff --git a/test/lisp/calendar/solar-tests.el b/test/lisp/calendar/solar-tests.el
index 7a37f8db55..dff64635e5 100644
--- a/test/lisp/calendar/solar-tests.el
+++ b/test/lisp/calendar/solar-tests.el
@@ -26,7 +26,7 @@ solar-sunrise-sunset
         (calendar-longitude 75.8)
         (calendar-time-zone +330)
         (calendar-standard-time-zone-name "IST")
-        (calendar-daylight-time-zone-name "IST")
+        (calendar-daylight-savings-starts nil)
         (epsilon (/ 60.0)))             ; Minute accuracy is good enough.
     (let* ((sunrise-sunset (solar-sunrise-sunset '(12 30 2020)))
            (sunrise (car (nth 0 sunrise-sunset)))

[-- Attachment #3: Type: text/plain, Size: 44 bytes --]


Does it look like TRT?  Thanks,

-- 
Basil

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

[Mattias Engdegård]

12 jan. 2021 kl. 21.06 skrev Basil L. Contovounesios <contovob@tcd.ie>:

> So I'm guessing dst-adjust-time adjusts for DST in my locale (based on
> some cache), but not yours?  The following change lets the test succeed
> for me:

Thank you, and I agree that it's probably the pragmatic choice. Much as I would have liked to track down and explain the exact reason for the observed phenomenon, I gave up and pushed your suggested patch.

If I would hazard a guess, it's related to the fact that Ireland uses daylight saving in winter (with opposite adjustment) rather than in summer; this may trigger a daylight-saving adjustment for the dates in question (late December). The fact that IST is used for both Irish and Indian time may be significant or a mere coincidence; it certainly didn't help matters.

Date and time calculations can be both infuriatingly and delightfully messy, but in this case the code didn't really help either, with way too many implicit input parameters -- global variables, caches, system settings, time-zone files, and so on. Not something to make a test writer happy!

Thanks again for the report, and for persevering!

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

[Basil L. Contovounesios]

Mattias Engdegård <mattiase@acm.org> writes:

> 12 jan. 2021 kl. 21.06 skrev Basil L. Contovounesios <contovob@tcd.ie>:
>
>> So I'm guessing dst-adjust-time adjusts for DST in my locale (based on
>> some cache), but not yours?  The following change lets the test succeed
>> for me:
>
> Thank you, and I agree that it's probably the pragmatic choice. Much as I would
> have liked to track down and explain the exact reason for the observed
> phenomenon, I gave up and pushed your suggested patch.
>
> If I would hazard a guess, it's related to the fact that Ireland uses daylight
> saving in winter (with opposite adjustment) rather than in summer; this may
> trigger a daylight-saving adjustment for the dates in question (late
> December). The fact that IST is used for both Irish and Indian time may be
> significant or a mere coincidence; it certainly didn't help matters.
>
> Date and time calculations can be both infuriatingly and delightfully messy, but
> in this case the code didn't really help either, with way too many implicit
> input parameters -- global variables, caches, system settings, time-zone files,
> and so on. Not something to make a test writer happy!

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.

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.

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

> Thanks again for the report, and for persevering!

Thanks for writing the test and making it more robust!  That's two of my
'make check' failures fixed in one day, only one to go :).

-- 
Basil

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

[Mattias Engdegård]

12 jan. 2021 kl. 23.09 skrev Basil L. Contovounesios <contovob@tcd.ie>:

> 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.

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

[Stefan Kangas]

Mattias Engdegård <mattiase@acm.org> writes:

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

I just assumed that the current calculations were correct and tested for
that.  This was to be able to verify that nothing changed when I turned
on lexical-binding for lunar.el.

Please do not assume that some deep thought that went into this: it's
more or less something I hacked together in an hour or three.  Feel free
to change any aspect of it if you think you can find something more
precise.

Thank you for working on this.

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

[Mattias Engdegård]

13 jan. 2021 kl. 14.04 skrev Stefan Kangas <stefan@marxist.se>:

> I just assumed that the current calculations were correct and tested for
> that.  This was to be able to verify that nothing changed when I turned
> on lexical-binding for lunar.el.

You are certainly forgiven for that assumption. I would have done the same. Thanks for writing it in the first place!

Now the test has been enabled again, in the hope that it will remain stable: the reference data have been corrected and are now in UTC, daylight saving disabled.

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

[Basil L. Contovounesios]

Mattias Engdegård <mattiase@acm.org> writes:

> Now the test has been enabled again, in the hope that it will remain stable: the
> reference data have been corrected and are now in UTC, daylight saving disabled.

Thanks, it passes here.

-- 
Basil