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
