develooper Front page | perl.datetime | Postings from December 2015

Announce: Astro::Sunrise 0.96 and DT::E::Sunrise 0.0505

From:
Jean Forget
Date:
December 8, 2015 06:18
Subject:
Announce: Astro::Sunrise 0.96 and DT::E::Sunrise 0.0505
Message ID:
1449555485.11297.2.camel@jf-xubuntu
I have released Astro::Sunrise version 0.96 last Thursday and 
DateTime::Event::Sunrise version 0.0505 yesterday.

With the previous versions, choosing the *precise* algorithm
could result in an infinite loop in some cases. See
https://rt.cpan.org/Public/Bug/Display.html?id=109992
and https://rt.cpan.org/Public/Bug/Display.html?id=110016

Actually, I think that there is a bug in the "precise" algorithm.  The
new versions are just a stopgap measure to prevent infinite loops. I
still have to check and overhaul the precise algorithm. See below the
test case given by the bug reporters. They show the sunrise and sunset
in a New Zealand location in November 2015. The times are given in
UTC, which is why the sun rises at "17:xx" and sets at "06:xx". As you
can see, the basic algorithm gives a regular variation of the sunrise
and sunset times, while the precise algorithm has some bizarre jumps.

With the precise algorithm
24 | 17:22 | 06:31
25 | 17:22 | 06:32
26 | 17:22 | 06:33
27 | 17:21 | 06:34
28 | 17:21 | 06:39
29 | 17:21 | 06:39
30 | 17:25 | 06:40

With the basic algorithm
24 | 17:25 | 06:32
25 | 17:24 | 06:33
26 | 17:24 | 06:34
27 | 17:24 | 06:35
28 | 17:23 | 06:36
29 | 17:23 | 06:37
30 | 17:23 | 06:38

So when I have a round tuit with "sunrise" written on it,
I will check the precise algorithm. But at least, now,
the loops will always exit, even if the returned value
is not right.

And many thanks to the people at http://geocoder.opencagedata.com/
who reported the bug.

Jean Forget




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About