Prayer time calculation is one of those problems that looks simple until you actually try to build it. Once you dig in, you’re dealing with astronomy, time zones, calculation standards, and edge cases that can easily break accuracy.
In this article, I’ll explain how prayer times are calculated, show JavaScript-based logic, and share how I applied it in a real website focused on Riyadh prayer times.
Why Prayer Times Aren’t Static
Prayer times are based on the sun’s position, not the clock. That means:
- Times change every day
- Location (latitude & longitude) matters
- Different regions follow different calculation methods
- Small errors = wrong prayer times
For cities like Riyadh, users expect high accuracy, not estimates.
Core Data Required
To calculate prayer times, you need:
1. Geographic Coordinates
For Riyadh:
- Latitude:
24.7136 - Longitude:
46.6753
These values are used to calculate solar angles.
2. Calculation Method
There are multiple standards:
- Muslim World League
- ISNA
- Egyptian
- Umm Al-Qura (Saudi Arabia) ✅
For Riyadh, Umm Al-Qura is the correct and widely accepted choice.
3. Time Zone
- Arabia Standard Time (UTC +3)
- No daylight saving time (simplifies things)
JavaScript Approach: Library vs Manual Math
You can write all astronomical math yourself, but in practice, most developers use a well-tested library.
A popular choice is Adhan.js, which implements official calculation methods correctly.
Example: Calculating Prayer Times in JavaScript
Here’s a simplified example using JavaScript logic similar to what libraries do internally.
import { PrayerTimes, Coordinates, CalculationMethod } from "adhan";
const coordinates = new Coordinates(24.7136, 46.6753);
const date = new Date();
// Umm Al-Qura method (Saudi Arabia)
const params = CalculationMethod.UmmAlQura();
const prayerTimes = new PrayerTimes(coordinates, date, params);
console.log({
fajr: prayerTimes.fajr,
dhuhr: prayerTimes.dhuhr,
asr: prayerTimes.asr,
maghrib: prayerTimes.maghrib,
isha: prayerTimes.isha
});
This handles:
- Solar angles
- Location
- Correct calculation method
- Daily variations
Formatting Times for Users
Raw Date objects aren’t user-friendly. You’ll usually want formatted output:
function formatTime(date) {
return date.toLocaleTimeString("en-US", {
hour: "2-digit",
minute: "2-digit",
hour12: true
});
}
formatTime(prayerTimes.fajr); // e.g. 05:12 AM
Real-World Implementation: Riyadh-Focused Website
I applied this logic in a production website dedicated entirely to this WebApplication:
Key decisions:
- City-specific focus (no geolocation guessing)
- Umm Al-Qura calculation method
- Daily recalculation for accuracy
- Cached results per day (performance)
- Clean, distraction-free UI
By narrowing the scope to one city, accuracy and speed both improved.
Common Mistakes to Avoid
If you’re building something similar, watch out for:
- ❌ Using the wrong calculation method
- ❌ Hardcoding prayer times
- ❌ Incorrect time zone offsets
- ❌ Not updating data daily
- ❌ Over-caching results
Prayer times are data-sensitive — small mistakes add up fast.
When APIs Make Sense (and When They Don’t)
APIs are great if:
- You need to visit many cities quickly
- You don’t want to manage calculations
Local calculation is better if:
- You want full control
- You need reliability
- Accuracy is critical
- You want offline support
For my use case, local calculation won.
Final Thoughts
Prayer time calculation is a great example of how domain knowledge matters as much as code.
If you’re building applications for real users — especially religious or time-sensitive ones — accuracy isn’t a “nice to have”, it’s essential.
Top comments (0)