You know, for something that sounds super simple—just getting the prayer times for Middlesbrough—you’d think any old website or phone app would nail it. Nope. Absolute rubbish, most of them. They are either jam-packed with ads, demand location permissions 24/7, or they calculate the timings using some ridiculous method that just doesn’t sit right with the local mosques. I wasn’t trying to build a NASA tracking station; I just needed five clean times on a screen.
The Messy Start: Fighting Bloat and Bad APIs
I started digging about a month ago. My goal wasn’t just to see the times; it was to build a display for my kitchen, something small, non-intrusive, maybe running on one of those cheap little micro-computers I had lying around. The first thing I did was what everyone does: I tried finding a public API.
Man, what a headache. I pulled data from three different ‘global’ calculation services. They all gave different answers. I’m talking a five-minute variance in Maghrib time, which is totally unacceptable. I had to manually input the specific geographic coordinates for central Middlesbrough, and even then, half the services had weird defaults. Some forced me into using Egyptian time calculation methods, or they assumed a very high latitude setting that made the summer Isha timing ridiculously late. I spent hours debugging why my output was showing Isha at 1:30 AM when locally it was accepted at 11:45 PM.
I scrapped all that expensive-looking junk. I realised I needed to go back to basics. What exactly was the accepted method used locally? I spent a good two days just reading forums and community guides, trying to understand the nuances of the calculation parameters used in the North East of England. I found out the exact angle parameters for Fajr and Isha that matched the local consensus. The existing apps weren’t just guessing; they were just using lazy, one-size-fits-all settings.
Stripping It Down: The Bare-Metal Approach
Once I had the parameters—the specific angles, the correct latitude adjustment, and the mandatory observance of British Summer Time changes—I decided to code the calculator myself. No more reliance on bloated third-party libraries that drag in ten megabytes of dependency just to run one equation.
I grabbed a super lightweight script framework. I poured in the core mathematical functions needed for astronomical calculations. I hard-coded the specific coordinates for Middlesbrough (54.57° N, 1.23° W).
Here’s the process I finally settled on:
- I set up the script to run precisely at 12:05 AM every night.
- It fetched the current date and the next day’s date.
- It ran the calculations using the custom angles I identified, making sure to specifically check the UK’s DST status for that day. This DST check was the killer feature; every off-the-shelf solution seemed to forget to handle the spring forward/fall back transition cleanly, resulting in an hour of missed data.
- I formatted the output into a simple JSON file—just key-value pairs like “Fajr”: “04:30”.
- Finally, I pushed that tiny file to a local server instance running on the micro-computer. The display device just read that single, clean file.
The whole script came out to maybe 150 lines of code, total. It was fast, it was reliable, and most importantly, it was locally accurate. I stripped away all the fat: no Qibla direction, no Dua library, no huge graphical interface. Just the times. Simple timings, exactly what the title promised.
Why I Needed This Precision (And Why You Should Too)
Why go to this much trouble for something so basic? Because trust me, when you need reliable data, you cannot rely on companies whose primary business is selling ads or mining user data. I learned that the hard way, not with prayer times, but with my old job.
Before I got into this stuff—building simple, functional systems—I worked in logistics. Massive contracts, international shipping, tight deadlines. My whole career depended on real-time data accuracy. One year, we had this massive system failure during a critical shipment bound for Teesport. The system we used, provided by a giant, well-known tech firm, just crashed and burned because they tried to update their global time zone library mid-process. It caused us to miss a tide window, costing the company a fortune.
I spent the next 72 hours fighting with their support team, trying to get the simple data extracted. They kept pointing fingers, saying it was network latency, when I knew darn well it was their unnecessarily complex timing management module. That disaster taught me one thing: the simpler the system, the more reliable it is. You cannot afford complexity when accuracy matters.
So, when it came to setting up the Middlesbrough Salah times, I vowed not to repeat that mistake. I refused to use bloated services that might update their calculation method next month and throw everything off. I built it myself from the ground up, ensuring that those five crucial timings are governed by rock-solid, verifiable calculations right here on my little machine. It runs perfectly, uses almost no power, and I never have to worry about whether some corporate developer in California decided to change the calculation angle for the North East of England.
It’s stable. It’s accurate. It’s done.