Skip to content
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

Open
iTarek opened this issue Nov 1, 2020 · 21 comments
Open

Automatic Adjust For Prayer Times Settings #41

iTarek opened this issue Nov 1, 2020 · 21 comments

Comments

@iTarek
Copy link

iTarek commented Nov 1, 2020

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

struct Countries: Decodable {
    let ISO: String
    let Madhab: Int
    let Method: String
    let HighLatitudeRule: String
}

 static func getPrayerSettingsForCountry(iso: String) -> Countries {
        let decoder = JSONDecoder()
        guard
            let url = Bundle.main.url(forResource: "Countries", withExtension: "json"),
            let data = try? Data(contentsOf: url),
            let countries: [Countries] = try? decoder.decode([Countries].self, from: data),
            let index = countries.firstIndex(where: { $0.ISO == iso })
        else {
            return (Countries(ISO: iso, Madhab: 1, Method: "muslimWorldLeague", HighLatitudeRule: "middleOfTheNight"))
        }
        
        return countries[index]
    }

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.

@z3bi
Copy link
Contributor

z3bi commented Nov 2, 2020

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.

@iTarek
Copy link
Author

iTarek commented Nov 2, 2020

Great, I will work on that...
for
looking to see if the latitude is above a specific value
I guess you can make option on enum HighLatitudeRule somthing like (.automatic) in adhan-swift, Is this hard to make?

@z3bi
Copy link
Contributor

z3bi commented Nov 2, 2020

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 🙂

@iTarek
Copy link
Author

iTarek commented Nov 8, 2020

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 ?

@z3bi
Copy link
Contributor

z3bi commented Nov 8, 2020

@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.

@basememara
Copy link
Contributor

basememara commented Jun 6, 2021

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.

@basememara
Copy link
Contributor

..also it feels this recommendation should change based on certain times of the year? Just throwing ideas out there

@z3bi
Copy link
Contributor

z3bi commented Jun 6, 2021

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.

@basememara
Copy link
Contributor

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.

@z3bi
Copy link
Contributor

z3bi commented Jun 7, 2021

Forgot to post a reference for my statement, see this article https://en.wikipedia.org/wiki/Twilight#Lasting_from_one_day_to_the_next

At latitudes greater than 48°34' North or South, on dates near the summer solstice, twilight can last from sunset to sunrise, since the Sun does not go more than 18 degrees below the horizon, so complete darkness does not occur even at solar midnight. These latitudes include many densely populated regions of the Earth, including the entire United Kingdom and other countries in northern Europe and even parts of central Europe.

@z3bi
Copy link
Contributor

z3bi commented Jun 7, 2021

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.

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.

@basememara
Copy link
Contributor

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:

Yukon, Canada / ISNA: Isha tonight is at 01:56 AM, but Fajr would be at 01:59, giving me 3 minutes to pray. I checked using a website (Islamicfinder.org) and the times for Isha and Fajr are 12:10 and 3:42 AM.

UK: many complaints about fajr at 1am didn't make sense to them

After update:

France / ISNA: I’ve noticed that Fajr time went from 3:59am to 4:59am in my area, why is that ? I’m always using 15 degree calcul angle and this new Fajr prayer time is not accurate considering the sunrise here. The angle used in the masajid here in my France city, is the 12 angle but in my area it turned out that while observing the sky at the time of Fajr, it was not correct to use this angle of calculation and that it is more appropriate to use the 15 angle or 18 angle according to others.

Brussels / UIOF (which I added in my app): with the update, the Fajr time difference is of about 45 mins so quite significant and I tend to wake up right at the start of time... The app update did not only affect Fajr time but Isha too, making it earlier at 11pm when there is still light outside... so I would suggest that the automatic opt-in at least does not apply to this region... it might be more valid to places like Scotland.

Manchester / ISNA: The times previously aligned with my local mosque but now at 18° elevation, we are given an hour for Fajr and Isha. Please...change the timings back to what they were (Fajr at around 1:10am)

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.

@z3bi
Copy link
Contributor

z3bi commented Jun 9, 2021

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.

@basememara
Copy link
Contributor

basememara commented May 1, 2022

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.

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?

@z3bi
Copy link
Contributor

z3bi commented May 1, 2022

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.

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.

@basememara
Copy link
Contributor

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 automatically adjusting prayer time settings, and providing as many options in the library to accommodate all masjid scenarios as a first step. Then creating the database of masjid/settings in major cities.

@z3bi
Copy link
Contributor

z3bi commented May 3, 2022

I recently was given the formula that masajid in Edmonton Canada use. I plan on adding a new calculation method for them inshallah.

@basememara
Copy link
Contributor

Had an idea about this.. what if we use TimeZone to broadly recommend a calculation method:

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 CLPlacemark returned from CLGeocoder().reverseGeocodeLocation(location:) to zero in on city, province, and/or country:

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 CalculationParameters because that allows us to fine tune the parameters, including elevation rule and adjustments.

Thoughts on going down this route and building the static database of TimeZone identifiers? Is it worth getting really specific with CLPlacemark?

@basememara
Copy link
Contributor

basememara commented Jul 13, 2022

I almost forgot there is also Locale that we can use as well:

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 TimeZone better because a lot of people customize their device locale regardless of where they live. TimeZone is not something people change much and it makes sense that TimeZone is correlated with prayer times.

@basememara
Copy link
Contributor

Salaam, I put up pr #72 to take a look and see if it makes sense.

@iTarek
Copy link
Author

iTarek commented Jul 17, 2022

This is the JSON file I use now with my app Prayer Times Today

Countries.txt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants