High latitude cities
Closed this issue · 8 comments
I tried to calculate prayer times for several high latitude cities e.x.:
Coordinates(latitude: 73.30, longitude: 80.31) // Krasnoyarsk Krai, Russia
Coordinates(latitude: 70.05, longitude: 27.53) // Nuorgam, Finlandbut no success and constructor returned nil.
Is there a bug that can be fixed? )
And about highLatitudeRule – can it be set automatically?
Maybe should the highLatitudeRule be linked with CalculationMethod itself? How can I determine when to change this property?
If the location is too far north or south and there is no sunrise/sunset, you will get nil if you do not specify a highLatitudeRule. Currently we do not set it automatically; there is no set rule for each calculation method per a given region.
In the future we want to suggest default settings based on location; the high latitude rule setting would be among those suggestions.
Actually, if you are seeing nil then there is no sunrise or sunset. I believe the ruling is to use the nearest valid latitude, so this is a bug. @z3bi can confirm.
Correct. I think the Islamic ruling would be to use "اقرب بلد" (nearest valid location) when calculating prayer times for a location that does not experience sunset/sunrise on that day. The way we can address this in the library is to iteratively move the latitude closer to the equator until a valid sunrise/sunset time can be computed. Something to discuss would be how much to move the latitude for each iteration.
Hi, is there any update or plan to work on this issue?
There is no current work being done to implement this in the library. We would welcome a PR or this can be entirely implemented by the application using the library and then simply moving the latitude closer to the equator if a nil value was ever returned. Just to note, the number of locations with inhabited cities that experience no sunset and no sunrise are extremely few.
Removing the bug label as this is the correct behavior. The reason for having a failable initializer was to account for these extreme scenarios.
Another thought on the issue would be to have a method that returned valid coordinates, that way the adjustment can be done once and the new valid coordinates could be stored, this would prevent having to do the costly adjustment on every calculation.
Stale issue message