Falak

The problem

Every year in Indonesia, people wait to hear when Ramadan, Syawal and Dzulhijjah begin. Sometimes different organisations announce different dates. They use different calculation criteria (hisab) for whether the new crescent moon, the hilal, can be seen. The government's sidang isbat combines calculation with sighting reports, but the public only hears the verdict.

Existing Hijri date converters are either lookup tables with no astronomy behind them, or official tools that give an answer without showing why. I built Falak for Muslims who want to check the dates and prayer times themselves, for teachers of ilmu falak in madrasah and pesantren, and for developers who want an open implementation.

What I built

I compute the sun and moon myself

I implemented standard published models for the sun's and moon's positions directly, with no outside astronomy service. The engine needs no API key and works offline. Every number the app shows traces back to a formula in the repository. Each answer, such as whether the hilal is visible, when Maghrib falls or which way the qibla lies, comes with a panel showing the raw figures behind it: altitude, elongation, moon age and lag time.

Three methods side by side

I implemented three competing criteria for crescent visibility: Wujudul Hilal, MABIMS-2021 and Odeh. Each runs independently, and the Awal Bulan page's criterion history shows where they agree and where they split. The app doesn't announce dates; it shows what each method computes for a given evening and place. The Indonesia map checks 3,255 points across the country, and on some evenings the visibility line cuts through Sumatra and Java, so the same date starts a different Hijri day depending on where you stand.

I validated the engine before building any screens

My build plan had one rule: no calculation feature ships without validation. Before any interface work, I checked the engine against JPL's DE440 ephemeris, a research-grade reference, for 50 historical new moons. Every one matched within five minutes. The reference library runs only in tests, never in the app. The Kalender page compares each method with past Kemenag announcements, entered from cited records only.

The whole app moved into the browser

The first version had a Django backend. Every endpoint was a pure calculation, the database only cached results, and the engine used nothing beyond standard maths, so it didn't need a server. I ported the engine to TypeScript and published a static site on GitHub Pages. Hosting costs nothing, and a server outage can't break it. The 3,255-point map now spreads across up to eight background threads instead of running on one.

The original engine checks the port

Two copies of a religious-calendar engine will drift unless something stops them. I kept the Python engine as the reference and froze its answers for 2,083 test cases across every kind of calculation the app does. The build replays them through the TypeScript port and blocks the deploy on any mismatch. To prove the suite actually catches drift, I broke the port three ways on purpose, a flipped threshold, a wrong lunar coefficient, a tiny sidereal-time offset, and each one failed the suite.

Result

Falak is live and free, with $0 hosting, comparing 3 hisab criteria across an Indonesia-wide 3,255-point visibility grid, entirely in the browser. It covers Hijri conversion, hilal visibility, prayer times with a printable monthly schedule, and the qibla with Rashdul Qibla, across five destinations plus a home instrument. The original feature set took about three days in July 2026; a browser migration and a full Indonesian-first redesign followed over the months after. A validation sweep in September caught a bug that could have started some months a day early under one criterion, found across 28 historical evenings and now closed with regression tests. The engine still matches all 50 historical new moons it's checked against JPL's ephemeris.