FAQ
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

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdatetime @
categoriesperl
postedDec 8, '15 at 6:18a
activeDec 8, '15 at 6:18a
posts1
users1
websitemetacpan.org...

1 user in discussion

Jean Forget: 1 post

People

Translate

site design / logo © 2019 Grokbase