Vedic Timekeeping as Precision Software: A Real-Time Muhurta Clock, Correct in Every Timezone
Muhurta Clock takes a tradition usually delivered as a static almanac and rebuilds it as precise, real-time consumer software. It fuses the three signals a practitioner actually cross-references — the current Choghadiya, the inauspicious Kalas (Rahu, Yamaganda, Gulika), and the midday Abhijit window — into a single at-a-glance verdict, then shows what's next: the next window worth planning around and the next to avoid. Underneath sits a full panchanga (Tithi, Nakshatra, Vara, Yoga, Karana) and all thirty muhurtas of the day and night, each computed from the user's own local sunrise and sunset. The defining engineering decision is where the computation lives: every timing calculation runs in the browser from the device's clock and geolocation, using a NOAA solar algorithm written in pure TypeScript — no backend is needed to know what time it is for you. That choice is also a correctness guarantee. The verdict is a pure function of local time and location, which a server rendering the page cannot know; server-rendering it would risk showing a confident answer that is simply wrong for the viewer's timezone. So during launch performance hardening the team held its Lighthouse score at 89 rather than pre-render a possibly-wrong verdict — correctness over score. The same codebase ships as a signed Android app: a Capacitor static export produces a Play-submission-ready AAB, giving the product web and mobile reach without a second implementation to keep in sync.
Key Metrics
Verdict correctness
Before
Static almanacs and IP-guessed servers can render a fast answer that is wrong for the viewer's timezone
After
The verdict is a pure client-side function of local time and geolocation — always computed for the user's actual here-and-now
Performance vs. honesty
Before
Server-rendering the verdict would raise the Lighthouse score
After
Lighthouse held at 89 by choice — a correct answer that renders after the client knows where it is, over a faster answer that might be wrong
Panchanga fidelity
Before
Sidereal/tropical mistakes produce a plausible-looking but incorrect panchanga
After
Lahiri ayanamsa applied only to Nakshatra/Yoga; Tithi/Karana elongation-based — the split documented and unit-tested
Reach
Before
Web-only, or a second native codebase to maintain
After
One Next.js codebase ships web plus a signed, Play-submission-ready Android AAB, with iOS built on a hosted macOS runner
Watch the Walkthrough
The Challenge
Vedic timekeeping is almost always shipped as a printed panchang or a lookup table: correct for one city, one day, frozen at publication. Turning it into live software means computing everything from the user's own sunrise and sunset, in their own timezone, updating as the clock moves — Tithi and Nakshatra from lunar and solar longitudes, thirty muhurtas from local solar noon, the Choghadiya and the inauspicious Kalas from weekday and daylight length. The hard part is not the astronomy; it is honesty. The single thing a user opens the app to learn is whether now is auspicious, and that answer depends entirely on where they are and what time it is locally. Any architecture that computes the verdict without the device's own clock and location can render a fast, confident, wrong answer — the worst possible failure for a tool people use to make decisions.
Why This Approach?
Where the time math runs
Entirely client-side — a NOAA solar algorithm in pure TypeScript, no backend for time
Sunrise, sunset, and every window derived from them depend on the device's location and clock. Computing them in the browser means the answer is always for the user's actual here-and-now, works offline once loaded, and needs no per-city data pipeline. It also keeps the astronomy auditable in one small, tested module rather than behind an opaque API.
Alternatives considered: Server-computed panchanga, a third-party ephemeris API, precomputed per-city tables
Server-rendering the verdict
Do not SSR the verdict — accept a Lighthouse score of 89 to guarantee correctness
The verdict is a pure function of local time and geolocation, which the server does not have at render time. Pre-rendering it would trade a real correctness guarantee for a vanity performance number — and could show a wrong 'good time' to someone in another timezone. Holding the score at 89 rather than shipping a possibly-wrong pre-rendered answer was the honest call, and the one the product is built around.
Alternatives considered: Pre-render the verdict for a faster score, guess timezone from IP, render a default city
Sidereal vs tropical longitudes
Lahiri (sidereal) ayanamsa for Nakshatra and Yoga; elongation-based Tithi and Karana
Nakshatra and Yoga depend on absolute position against the fixed stars, so they need the sidereal correction. Tithi and Karana depend only on the Moon-minus-Sun elongation, where the ayanamsa cancels — applying it there would be double-counting. Getting this split right is the difference between a real panchanga and a plausible-looking one.
Alternatives considered: Apply the ayanamsa everywhere, or ignore it everywhere
Web and mobile delivery
One Next.js codebase; Capacitor static export produces a signed, submission-ready Android AAB
The computation is already client-side TypeScript, so the same UI runs natively with no second implementation. A Capacitor static export plus a signed release build yields a Play-submission-ready AAB, and iOS builds on a hosted macOS runner — web and mobile reach from a single source of truth, not two codebases drifting apart.
Alternatives considered: A separate native app, a webview wrapper with a divergent codebase, web-only
Accounts, storage, and billing coupling
All optional dependencies (ark-auth, PostgreSQL, ark-pay), each degrading gracefully when unset
The core clock must work for an anonymous first-time visitor with nothing provisioned. Accounts, server-side chart storage, and billing layer on top: with them the app saves charts and gates premium features; without them the login-free localStorage flow still runs. The browser never talks to the payment rail directly — billing calls go through the app's own server-side handlers that hold the admin token.
Alternatives considered: Require a login and database to run, call the payment rail from the browser
Build Process
Astronomy core in the browser
A pure-TypeScript solar/lunar layer computes sunrise and sunset (NOAA algorithm) and the panchanga — Tithi, Nakshatra, Vara, Yoga, Karana — with the Lahiri ayanamsa applied only where sidereal position matters and elongation used where it cancels. No backend participates in telling the user what time it is for them.
The verdict engine
getNowVerdict(now, lat, lon) fuses the active Choghadiya, the inauspicious Kalas (Rahu / Yamaganda / Gulika), and the Abhijit window into one three-way verdict — auspicious, neutral, or avoid — under a fixed precedence: an active kala overrides everything, Abhijit is premium-auspicious, otherwise the Choghadiya quality decides. The same window helpers feed the 'what's next' planner and the full-day scan, so the fusion rules live in exactly one place.
Correctness-first performance hardening
During launch tuning the team refused to server-render the verdict, because the server cannot know the viewer's timezone or location. The result is a Lighthouse score capped at 89 by an intentional, defensible choice — a correct answer that renders after the client knows where it is, rather than a faster answer that might be wrong.
Web + mobile from one source
A Capacitor static export of the same app produces a signed Android release AAB that is ready to submit to Google Play, with iOS builds handled on a hosted macOS runner. Because the timing logic is already client-side, mobile is the same product — not a fork.
Challenges & Solutions
Impact
Server-rendering the 'is now auspicious?' verdict would boost the performance score, but the server has no way to know the viewer's local time or location — so it could confidently render a verdict meant for the wrong place.
Solution
Compute the verdict client-side as a pure function of local time and geolocation, and accept the performance cost of not pre-rendering it — a Lighthouse score held at 89 by choice.
Result
The verdict a user sees is always computed for their actual here-and-now; correctness is structural, not a disclaimer.
How AI Powers This
AI Capability
AI Muhurta Advisor
Beyond the raw windows, users can ask what a given moment is good for and get Jyotish-style guidance grounded in the same computed kala and muhurta windows the clock already shows.
Business outcome
A production audit confirmed the advisor returns real muhurta advice with computed kala windows attached — the AI explains the math, it does not replace it.
Under the hood
The advisor endpoint routes through ark-proxy, which auto-upgrades the underlying model — no hardcoded model version — and grounds its response in the app's own computed windows rather than free-associating.
How success is measured: Guidance consistency with the computed verdict, relevance to the asked activity, no contradiction of the deterministic windows
AI Capability
Auspicious Activities
Tells a user what the current window favours — which kinds of undertaking suit the active Choghadiya and muhurta — turning an abstract verdict into a concrete, actionable suggestion.
Business outcome
Verified in the production audit to return structured activity recommendations for the live moment.
Under the hood
A structured-recommendation endpoint over the same ark-proxy gateway, keyed to the deterministically computed current windows so suggestions always agree with the clock.
How success is measured: Structured-output validity, alignment with the active window's quality, usefulness of the suggested activities
Results & Metrics
Verdict correctness
ImprovedBefore
Static almanacs and IP-guessed servers can render a fast answer that is wrong for the viewer's timezone
After
The verdict is a pure client-side function of local time and geolocation — always computed for the user's actual here-and-now
Performance vs. honesty
ImprovedBefore
Server-rendering the verdict would raise the Lighthouse score
After
Lighthouse held at 89 by choice — a correct answer that renders after the client knows where it is, over a faster answer that might be wrong
Panchanga fidelity
ImprovedBefore
Sidereal/tropical mistakes produce a plausible-looking but incorrect panchanga
After
Lahiri ayanamsa applied only to Nakshatra/Yoga; Tithi/Karana elongation-based — the split documented and unit-tested
Reach
ImprovedBefore
Web-only, or a second native codebase to maintain
After
One Next.js codebase ships web plus a signed, Play-submission-ready Android AAB, with iOS built on a hosted macOS runner
Resilience
ImprovedBefore
Apps that require a login and database to render anything
After
Accounts, chart storage, and billing are all optional and degrade gracefully — the login-free clock always works
System Overview
The architecture below is the technical foundation behind every business outcome on this page — built for reliability, low running cost, and the speed your customers feel.
A Next.js SSR app (output: standalone) deployed in binary mode to a VPS systemd unit on 127.0.0.1:3118 behind the Cloudflare vps-tunnel, health at /api/health. All timing computation is client-side pure TypeScript: a NOAA solar algorithm derives local sunrise/sunset, from which the panchanga (Tithi/Nakshatra/Vara/Yoga/Karana, Lahiri ayanamsa where sidereal), the thirty day/night muhurtas, the Choghadiya, and the inauspicious Kalas are computed. verdict.ts fuses the live signals into one three-way verdict under a fixed precedence, reused by the upcoming-windows planner and the full-day scan. AI features (Muhurta Advisor, Auspicious Activities) route through ark-proxy with a proxy-upgraded model and are grounded in the deterministically computed windows. Accounts use ark-auth JWTs, server-side chart storage uses postgres.js (schema bootstrapped on first use), and billing goes through ark-pay via server-side handlers that hold the admin token — the browser never calls the payment rail. All three are optional and degrade gracefully; the login-free localStorage flow always works. The same codebase exports statically via Capacitor to a signed Android AAB (submission-ready) with iOS builds on a hosted macOS runner.Technologies Used
Next.js (SSR, standalone), React, TypeScript, Tailwind 4, client-side NOAA solar math, PostgreSQL (postgres.js), Capacitor (Android/iOS), ark-auth, ark-pay, ark-proxy, Vitest, systemd binary deploy