Software · Astronomy
The astronomy has been settled for centuries. The conventions built on top of it differ between communities, and I did not appreciate by how much until I tried to put them into software.
I started Ummah Salah expecting a weekend of work. The sun's position on a given date at a given latitude is one of the most thoroughly solved problems in science. There are well-tested libraries for it. You feed in coordinates and a date, you get back five times, and you are finished.
That part took an afternoon. The rest took considerably longer, because computing prayer times is not really an astronomy problem. They are an astronomy problem wrapped in several centuries of scholarly judgement, and the judgement is where the engineering difficulty lives.
Three of the five times are close to uncontroversial. Dhuhr begins just after the sun crosses its highest point. Maghrib begins at sunset. Both are directly observable — you can stand outside and watch them happen — and every timetable agrees to within a minute or two.
Asr is fixed by shadow length rather than by the sun's angle, which is also unambiguous, right up until you ask which shadow length. Most schools hold that Asr begins when an object's shadow equals its own length plus whatever it cast at noon. The Hanafi school uses twice the object's length. That is not a rounding difference; it moves the time by thirty to sixty minutes. Mosque timetables in London routinely print both columns.
Fajr and Isha are the problem. Both depend on twilight — the first light of dawn and the last of dusk — and twilight does not have a sharp edge. The convention is to define it by how far the sun has sunk below the horizon, but the number is a judgement call, and different bodies made different calls.
The Muslim World League uses 18° for Fajr. ISNA, widely followed in North America, uses 15°. The Egyptian General Authority of Survey uses 19.5°. Umm al-Qura in Makkah uses 18.5° for Fajr and then abandons angles entirely for Isha, fixing it at ninety minutes after sunset.
None of these is wrong. They are different readings of when first and last light occur, and the gap between them is substantial — at the extremes, most of an hour. So the first real design decision in a prayer times application is not technical at all. It is: whose opinion do you show by default, to someone who has not told you anything about themselves?
Above roughly 48° of latitude, the whole framework breaks down for part of the year.
The sun's lowest point each day is at solar midnight, and how low that is depends on your latitude and the time of year. In London around the summer solstice, the sun gets about 15° below the horizon and no further. So an 18° Fajr does not occur late; it does not occur at all. There is no moment that satisfies the definition.
I ran the numbers while building the site. London fails to reach 18° for 59 days a year, from late May to late July. Glasgow, only four degrees further north, fails for 96 days — and at midsummer the sun there reaches barely 11° down, which is not even deep enough for nautical twilight.
For those weeks the times have to be derived rather than observed. The usual approaches divide the night into portions — halves, sevenths — or scale the angle down. Communities genuinely disagree about which to use, and it is a question of religious judgement rather than a bug to be fixed.
What a piece of software can do is be honest about it. The site marks those times as estimated when it happens, rather than quietly handing you a number that looks exactly as authoritative as the ones either side of it.
The library I used has a function that recommends a high-latitude rule based on your coordinates. I used it, because that is what it is for.
Some while later I checked its output against a real London timetable and found Fajr reading 04:36 where it should have read 03:50. The recommended rule was the seventh-of-the-night method, which does not only apply during the weeks when the angle is unreachable — it clamps the time all year. In London it was overriding a perfectly valid 18° Fajr on roughly 157 days a year, by as much as 173 minutes.
Switching to the middle-of-the-night rule fixed it. That rule only binds when the angle genuinely cannot be reached, which is the behaviour you actually want: use the real answer where one exists, fall back only where none does.
That was the first point at which I stopped trusting sensible-sounding defaults and started checking every one against published timetables. It would have shipped silently, and almost nobody would have been able to tell me why the number was wrong — only that it did not match the mosque.
The last problem was the one I had least expected, and it is specific to where I live.
Most mosques inside the M25 — including East London Mosque and London Central Mosque — do not use a calculation. They follow the London Unified Prayer Timetable, a published table agreed between mosques, adopted partly to deal with exactly the persistent-twilight problem above.
I spent some time trying to reverse-engineer it into settings. You can work backwards from a published time to the sun angle that would produce it, so I did that for a year of dates to find the parameters.
There are no parameters. The implied Fajr angle drifts from about 14° in late summer to 16.4° in midwinter. Isha is worse: 15.6° in winter collapsing to 10.5° in summer, because the timetable deliberately compresses the summer to stop Isha drifting towards midnight. Around the June solstice, Fajr simply sits pinned at the same clock time for eight consecutive days, which is not something any angle produces.
I fitted a Fourier series to a full year of it — a reasonable approach for a smooth seasonal signal — and got within four or five minutes. Better than a generic method by an order of magnitude, and still not right. A five-minute error in Fajr is not a rounding difference to the person relying on it.
So the site carries the published timetable itself as data rather than pretending to compute it. That felt like a defeat at the time and was obviously correct in hindsight. Some things are conventions rather than consequences, and a convention cannot be derived — it can only be looked up.
This is not religious guidance. I am a developer, not a scholar. Everything above describes why the engineering is difficult and what different authorities do; none of it is an opinion on which of them you should follow. Where this and your local mosque disagree, follow your mosque.
A single page that loads in a few tens of kilobytes, calculates everything on your own device so no location data is transmitted anywhere, works without an account, and carries no adverts or tracking of any kind.
It names the method it is using on the face of the page rather than burying it in settings. It explains every option in plain language, including the ones most applications present as a bare number of degrees. It shows a diagram of the sun's full twenty-four-hour path with the horizon drawn through it, because Fajr and Isha both happen below that line and that single fact makes them far easier to reason about. And where a region has an agreed timetable, it offers that timetable rather than an approximation of it.
The thing I did not anticipate is how much of the work turned out to be epistemological rather than technical. Not "what time is Fajr", but "on what basis am I telling you that, and how would you know if I were wrong". Which, on reflection, is the same question I spend most of my time on in the tax software — showing the working, so a figure can be checked rather than trusted.
It is free and it is at ummahsalah.com.
Written by Ryan Kalagin, a UK-based software and product developer with eight years' background in banking. He builds tools for private investors. Find him on LinkedIn.