-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic Adjust For Prayer Times Settings #41
Comments
JazakAllahu khairun for your contribution Tarek! It probably is time to go ahead and start creating a list of calculation values per country. We should start with ones we are more sure about and then just not have entries for locations we aren't sure about. Otherwise people may not know we are looking for contributions. If we can trim this list down to only locations we have a degree of certainty about that would be great. I think we can also make things like "madhab" optional as there are a lot of places where that will vary from person to person, but in some countries the overwhelming majority does a follow a specific madhab and we can provide that for them. For high latitude rule, I actually don't suggest applying it by country, but rather looking to see if the latitude is above a specific value or not. |
Great, I will work on that... |
Yeah I think a static func that took the latitude as a parameter and then returned a highLatitudeRule would work. I'll put up a PR for that 🙂 |
One of the users of my prayer time app recently requested the addition of the UOIF calculation method as it is the predominant method in France. They are using 12 degrees for Fajr and Isha in order to create more reasonable times. Wonder why adhan-swift don't have this in CalculationMethod ? |
@iTarek the value of ~18 degrees that most locations use is based on the concept of "astronomical twilight". Some methods go up and down a little bit, but stay close to these values. But the value of 12 degrees seems to be a way to try and get a time that you want but is not really based on the position of the sun that all other locations use. For that reason I have never added it as it doesn't make any sense to me. Instead I have the calculation method "moonsighting committee" which adjusts the times based on the season, which more accurately reflects prayer times in Northern Europe and North America. There is an article from the Fiqh Council of North America that talks about this exact issue here http://fiqhcouncil.org/fifteen-or-eighteen-degrees-calculating-prayer-fasting-times-in-islam/ Adhan does have the ability to use "custom methods" and set the fajr angle and isha angle manually, so you can always do that. |
Wondering how the recommended high altitude threshold being set at 48 degrees was determined, and if this value should differ per calculation method? For example, for Moonsighting calculation they state that 1/7 is used for latitudes between 55 degrees. |
..also it feels this recommendation should change based on certain times of the year? Just throwing ideas out there |
At around 48 degrees is when you start to see locations not have cessation of twilight (it never gets dark enough for isha time to actually arrive). When using the high latitude rule it only applies the rule if the normal calculation results in a more difficult time (later time for fajr and earlier time for isha). So for most of the year the rule actually does nothing. The high latitude rule tends to only change times around the summer solstice. |
JAK for the explanation, also for @iTarek bringing this up and the database. I'm wondering if it will be more efficient and even more accurate if we were to create a database of the major mosques around the world. Then find out which prayer calculation method they use and assign it to the mosque in the database. From there, the masjid that is the closest distance to the user's coordinates is the recommended calculation method. |
Forgot to post a reference for my statement, see this article https://en.wikipedia.org/wiki/Twilight#Lasting_from_one_day_to_the_next
|
That might be a bit harder to do in the US where different masjids in the same city are using different calculation methods. I've been trying to gather official sources for Muslim countries since that should be unified at least. |
I hope I'm not diverting the original intent of this thread, but I think auto calculating high latitude is still in the same topic. I put this auto high latitude rule in production and wanted to share some observations from users: Before update:
After update:
I let them they can manually change the elevation mode to middle of the night to lock it how it was so it's an easy resolution, and to try another calculation like Moonsighting to see if it better matches their local masjid, but sharing here for glimpses of your own apps and maybe improve a way to surface or reconcile these situations during the season. I'm actually rethinking my onboarding flow entirely so they can manually check it against a local masjid before proceeding, and also better communicate updates clearly or seasonal notifications and Ramadan check-ins about nudging the user to manually check against their local masjid. |
So for the UK you should definitely default to Moon Sighting Committee, thats what most masjids in the UK use. As far as France and Brussels, I've never really understood the 12 degree angle that some masjids use there. As far as I can tell the 12 degrees is a way to prevent extreme values in the summer. But thats also what the high latitude rule is for, so it may not make sense to use the high latitude rule if you are setting a 12 degree method. |
Salaam, gathering more data and seems like angle-based instead of 1/7 works better for >48° latitude. It looks like IslamicFinder and Muslim Pro are defaulting to angle-based for northern regions. I'm wondering if the recommended high latitude logic needs to be more sophisticated, maybe even using one recommendation for fair and another for isha. Does this make sense or any thoughts around this? |
I'm curious how do you define "works better"? In this case normal prayer time definitions simply don't work and now it is a matter of Islamic fiqh. The reason we default to 1/7 is that is an established ruling from fiqh. The "angle based" option was added to allow flexibility since I noticed this was being used by IslamicFinder as well. I'm very hesitant to change default values though simply because IslamicFinder does it, I like to find more authoritative reasoning if possible. |
Agreed about not changing the default, especially since its an approved fiqh and a matter of preference from there. During Ramadan, got a lot of reports from Edmonton, Alberta and other northern cities in Canada. I was validating these claims with mainstream masajid in their areas. It's just that IslamicFinder was just supporting it on top. Vancouver was another city where masajid were using angle-based. It's weird but noticed some masajid were even using angle-based for fair and 1/7 for isha and wondering if this is something common in other areas where we maybe should provide a 4th elevation rule option for mixed rule, or decouple fair and isha night portions so they can be set separately instead of the single tuple for fair/isha. In my UI, I try to make it clear don't trust the app or any app but to adjust the settings to match their local masjid. I think this is still within context of the original post of |
I recently was given the formula that masajid in Edmonton Canada use. I plan on adding a new calculation method for them inshallah. |
Had an idea about this.. what if we use public extension CalculationMethod {
/// Returns the recommended Calculation Method for the specified time zone.
static func recommended(for timeZone: TimeZone = .current) -> CalculationMethod {
switch timeZone.identifier {
case "Africa/Cairo":
return .egyptian
case "Asia/Dubai":
return .dubai
case "Asia/Karachi":
return .karachi
case "Asia/Kuwait":
return .kuwait
case "Asia/Qatar":
return .qatar
case "Asia/Riyadh":
return .ummAlQura
case "Asia/Singapore":
return .singapore
case "Asia/Tehran":
return .tehran
default:
return .moonsightingCommittee
}
}
} And if we really want to get specific, we can use the public extension CalculationParameters {
/// Returns the recommended Calculation Method for the specified geographic data.
static func recommended(for placemark: CLPlacemark) -> CalculationParameters? {
let city = placemark.locality ?? placemark.subAdministrativeArea
let province = placemark.administrativeArea
let countryCode = placemark.isoCountryCode
switch (city, province, countryCode) {
case (_, _, "EG"):
return CalculationMethod.egyptian.params
case (_, _, "IR"):
return CalculationMethod.tehran.params
case (_, _, "KW"):
return CalculationMethod.kuwait.params
case (_, _, "PK"):
return CalculationMethod.karachi.params
case (_, _, "QA"):
return CalculationMethod.qatar.params
case (_, _, "SA"):
return CalculationMethod.ummAlQura.params
case (_, _, "SG"):
return CalculationMethod.singapore.params
case (_, _, "SG"):
return CalculationMethod.singapore.params
case (_, _, "SG"):
return CalculationMethod.singapore.params
case (_, _, "TR"):
return CalculationMethod.turkey.params
case (_, _, "AE"):
return CalculationMethod.dubai.params
default:
return CalculationMethod.moonsightingCommittee.params
}
}
} Notice in the latter case I made the extension off of Thoughts on going down this route and building the static database of |
I almost forgot there is also public extension CalculationMethod {
/// Returns the recommended Calculation Method for the specified locale.
static func recommended(for locale: Locale = .current) -> CalculationMethod {
switch locale.regionCode {
case "EG":
return .egyptian
case "IR":
return .tehran
case "KW":
return .kuwait
case "PK":
return .karachi
case "QA":
return .qatar
case "SA":
return .ummAlQura
case "SG":
return .singapore
case "TR":
return .turkey
case "AE":
return .dubai
default:
return .moonsightingCommittee
}
}
} ..but I like using |
Salaam, I put up pr #72 to take a look and see if it makes sense. |
This is the JSON file I use now with my app Prayer Times Today |
I know that you have plan to include automatic adjust for prayer times, and right now I am working on update for Ela-Salaty and I will use adhan-swift for that...
I already have database with all countries I converted it to json and added adhan-swift paramters...
Please check the json here...
https://www.dropbox.com/s/52kcom2vg1cagq4/Countries.json?dl=1
I use this func to get prayer settings for a country iso
I don't know if this good enough for you, or you have a better solution, but I thought I should share this anyway it could be seed to smothing bigger.
The text was updated successfully, but these errors were encountered: