GNU bug report logs - #45818
28.0.50; Test solar-sunrise-sunset fails

Previous Next

Package: emacs;

Reported by: "Basil L. Contovounesios" <contovob <at> tcd.ie>

Date: Tue, 12 Jan 2021 16:29:01 UTC

Severity: normal

Found in version 28.0.50

Done: Mattias Engdegård <mattiase <at> acm.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Stefan Kangas <stefan <at> marxist.se>, 45818 <at> debbugs.gnu.org
Subject: bug#45818: 28.0.50; Test solar-sunrise-sunset fails
Date: Tue, 12 Jan 2021 22:09:05 +0000
Mattias Engdegård <mattiase <at> acm.org> writes:

> 12 jan. 2021 kl. 21.06 skrev Basil L. Contovounesios <contovob <at> 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




This bug report was last modified 4 years and 127 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.