Accuracy

What we measured, and what we still get wrong

Every figure on this page comes from a regression report generated by the test suite. Where we have not measured something, we say nothing rather than estimate.

Government / PAC reference

Panchang Accuracy & Validation

An independent comparison of our output against reference data published by the Government of India's Positional Astronomy Centre.

TathaAstu Panchang calculations have been independently compared by us with reference data published by the Government of India's Positional Astronomy Centre (PAC) — the Rashtriya Panchang (Saka 1948) and PAC's Eclipses 2026.

In our 2026–2027 comparison, tithi and nakshatra transition times matched the reference to within its published one-minute precision across the compared dates, names agreed (aside from romanization variants), and eclipse type and timing matched to the minute — with no confirmed calculation discrepancies.

This is an independent technical comparison and does not imply Government certification, approval, or endorsement.

PAC — Eclipses 2026 Positional Astronomy Centre (PAC)

Verification

Three tiers, three different failure modes

Each tier catches something the others cannot. Reference comparison catches a wrong rule. The determinism lock catches a rule change that moved an unrelated date. Audit replay catches a deployment that diverged from what was audited.

Tier A

42 / 42

Reference comparison

vs DrikPanchang

7 festivals × 6 years, spanning 1950–2100

Diwali, Janmashtami, Maha Shivaratri, Ganesh Chaturthi, Vijayadashami, Holi and Makar Sankranti are compared against DrikPanchang across a 150-year span. This catches rules that happen to be right for the current decade but wrong historically.

DiwaliJanmashtamiMaha ShivaratriGanesh ChaturthiVijayadashamiHoliMakar Sankranti

Tier B

Locked

Determinism lock

vs Itself

Every-day festival hash across 8 years

A hash of every festival on every day for eight years is stored in tier_b_lock.json. Re-running the engine must reproduce it exactly. This is the guard against silent drift: change a rule for one festival and accidentally move another, and the lock breaks immediately.

Tier C

26 / 26

Audit replay

vs Production data

22 days from the 2026–27 accuracy audit

Assertions taken from a manual accuracy audit are replayed against production. Where Tier A proves agreement with an external reference, Tier C proves the deployed system still behaves as audited.

Regression testing

152 automated tests · 91% Festival Engine V2 coverage

The regression suite runs on every build. The Festival Engine V2 coverage gate is 90%; builds below the gate do not ship.

Test area	Tests	What is covered
Festival Engine V2	115	Evaluators, calendars, intervals, tie-breaking, validation, database integration and materialisation
API plan & access controls	16	Plan gating and Enterprise compatibility
Webhooks	21	Signing, retries, delivery outcomes and idempotency
Total	152	91% Festival Engine V2 coverage

Coverage measurement

The current figure reflects the present Festival Engine V2 codebase and its regression suite. The coverage gate is 90%, and the current measured coverage is 91%. Coverage figures are maintained as part of our regression and release process.

Performance

Measured on production, not a laptop

Measured production observations (10 warmed samples per endpoint through the public API on 2026-08-20), not guarantees. Latency varies with cache state, load and request parameters.

End-to-end, production

Endpoint	Median	p95
/v1/panchang	~35 ms	~42 ms
/v1/festivals	~95 ms	~122 ms
/v1/festivals/explain	~118 ms	~238 ms

Cold cache — /v1/festivals/year

The first request for an uncached (year, location) on /v1/festivals/year can take up to ~20 seconds while the full year is derived. Subsequent cached requests return in well under a second. Pre-warming commonly requested year/location combinations is planned.

Engine-level

Metric	Measured	Target
Festival lookup p95	2.4 ms	< 50 ms
Full year sweep	0.8 s	< 5 s

On the numbers you may have seen elsewhere

An earlier version of this website claimed sub-50 ms responses. That figure described engine-side lookup, not an API round trip, and presenting it as a response time was misleading. Real end-to-end p95 ranges from ~42 ms (Panchang) to ~238 ms (festival explain), and a cold festival-year derivation can take much longer — see the cold-cache note. We have corrected it.

Coverage

What is verified, and how far

Panchang data

15 locations precomputed · worldwide on request

Precomputed and gap-checked for the 15 production locations. Any other location is computed on request from its coordinates, on the same engine — pass lat, lon and an IANA timezone.

Festival derivation

location-aware

Festival dates are reference-verified for New Delhi across Tier A, B and C. The same rules run for any location: because a Hindu day is bounded by local sunrise, the occurrence date can differ abroad — Raksha Bandhan 2026 is 28 August in Delhi and Sydney, 27 August in Paris and New York. Locations other than New Delhi are computed through the same engine but are not yet separately reference-verified.

Historical span

1950–2100

Tier A compares across a 150-year window specifically to catch rules that are correct for the present decade and wrong historically.

Determinism

8 years, every day

Tier B hashes every festival on every day across eight years. Any unintended change breaks the lock on the next run.

Ayanamsa

Lahiri

The Indian standard for sidereal calculation. Kala definitions follow Dharmasindhu and Nirnayasindhu conventions, which is why comparison against DrikPanchang is meaningful.

Corrections shipped

Defects we found and fixed

These were real errors in production before Festival Engine V2. We list them because a platform that claims never to have been wrong is not one you should trust.

Festival	Was	Now
Diwali / Lakshmi Puja	Missing entirely	Amavasya prevailing at Pradosha
Krishna Janmashtami	Missing entirely	Nishita-vyapini Ashtami (Smarta default)
Ganesh Chaturthi	One day late	Madhyahna-vyapini
Vijayadashami	One day late	Aparahna-vyapini
Maha Shivaratri	One day late	Nishita-vyapini
Holi	Wrong when Purnima ended before sunset	Holika Dahan + 1 day, as a series
Abhijit Muhurat	Suppressed by Rahu/Yamaganda overlap	Always returned; overlaps listed separately

Known limitations

What is still wrong, in our own words

This list is the actual contents of our internal limitations document. We would rather you find a limitation here than discover it in production.

✓ Recently resolved in the 2026-08-19 GREEN regeneration: Krishna-paksha amanta_month_key labeling was corrected and validated across 128,006 days, and all 15 production locations now have complete 1700–3100 Panchang data (7,675,560 day rows).

Open

Regional festival rule variants are largely unauthored

Seven packs are registered — North India, West India, East India, South India, Kashmir, Nepal and Sri Lanka — and the pack mechanism is implemented and tested. What is thin is the content: all but one festival rule carries no regional scope, so it applies everywhere, and only one is scoped to a specific region. Variants that genuinely differ by tradition — Gujarati, Tamil, ISKCON — are not yet authored.

ImpactA festival date is the common rule unless a rule declares otherwise, so naming a regional pack usually returns the same date rather than a tradition-specific one. This is a limit on festival rule content, not on location: Panchang itself is computed for any coordinates worldwide, with the local timezone and daylight saving applied.OwnerPanchang Platform v2.1

Open

Festival pre-materialisation covers location 1 only

Panchang data is complete for all 15 locations (1700–3100). This is a separate cache layer: the nightly job pre-materialises festival results for a rolling window at location 1 only. Festival requests outside that window — notably a full year via /v1/festivals/year for another location or a distant year — are derived on demand.

ImpactCorrectness is unaffected. But the first uncached /v1/festivals/year request can take up to ~20 seconds while the year is derived; cached requests then return in well under a second. Pre-warming common combinations is planned.OwnerMulti-location / multi-year festival materialisation

Open

Webhooks are one-way and at-least-once

There are no inbound webhooks. Delivery is at-least-once, so subscribers must deduplicate on X-TathaAstu-Event-Id. Retries stop after 5 attempts; endpoints auto-disable after 20 consecutive failures.

ImpactIntegrations must be idempotent. This is a design choice, not a defect.OwnerBy design

Philosophy

How we handle being wrong

Rules are never edited in place

A correction inserts a new rule version pointing at the row it supersedes. The old row is marked DEPRECATED, not deleted. Any response we served in the past can still be reproduced from its recorded rule id and version.

Every correction is traceable to a reason

Traces record the rule, its version, the evaluator, the overlap in minutes, and the shastric authority. When a date changes, you can see precisely which rule changed and why.

Limitations are published, not buried

The list above is the actual contents of our internal KNOWN-LIMITATIONS document. We would rather you find a limitation here than discover it in production.

A number we cannot measure is not a claim we make

Every figure on this page comes from a regression report generated by the test suite. Where we have not measured something, we say nothing rather than estimate.

Report a date you believe is wrong

Send the request you made and the value you expected. Accuracy reports are triaged ahead of everything else. If you are right, the fix ships as a new rule version and appears in the changelog.

Report an accuracy issue Read the methodology